From One Expert to Another: Catherine Powell


In this installment of From One Expert to Another, our interview series in which software practitioners talk shop, tester Dave Liebreich asks tester and manager Catherine Powell ten questions about ideal tester skills, testing in unfamiliar domains, the value of managers who test, and more.

Catherine Powell has been testing and managing testers and development teams for about ten years. She has worked with a broad range of software and focuses primarily on the realities of shipping software in small and mid-size companies. Catherine’s published works, blog, and contact information can be found at

Dave Liebreich : What excites you about testing? Why do you keep doing it, and what frustrates you about it?

Catherine Powell: The exciting thing about testing is also the frustrating thing about testing: the uncertainty. We can gain knowledge, disseminate information, and decrease risk, but we can never guarantee that something will work, and we’re never done. Every time we ship software, I hold my breath until we see it working, and then there’s a gleeful moment. It’s like working on a roller coaster without seat belts—boy, what a ride!

DL: How would you describe your ideal co-tester?

CP: I’ve worked on a lot of test teams—some more successful than others. The most successful test teams I worked on were very diverse; each of us had very different skills and approaches. My ideal co-tester, then, is someone who is not like me. I want someone I get along with and who has strong skills in areas I’m less good at.

DL: Speaking of skills, we’ve both tested computing infrastructure systems. What testing skills do you think transfer between that domain and other domains, such as enterprise software, web applications, and such? What skills don’t?

CP: There are so many things to test, and many of us will test a lot of different kinds of things! The good news is that, at some base level, testing is testing and most of our testing skills apply:

  • The ability to clearly communicate behavior and its effects
  • An understanding of how to work with a large variety of people
  • The ability to learn jargon and use it effectively
  • Mental modeling of a system and how all the pieces fit together
  • “Peripheral vision” to see defects and system behaviors, even when that’s not what we meant to look for

Tools and the domain knowledge do not translate between different types of products, but don’t be afraid of that. Your ability to learn quickly will help you overcome any difficulties.

DL: So, what kind of things do you think about when you are testing on a project in a new or unfamiliar domain?

CP: Different kinds of projects have the same needs, but in different quantities. For example, I worked on one project where the system could be slow, and it could be ugly, but the calculations had to be accurate and system downtime was a very big problem. We did a lot of functional and reliability testing, but no performance or usability testing. I worked on another project that was being sold as “like its competitors but easy to use,” and on that project we spent a lot of time on usability testing while skimping a bit on reliability testing. Downtime was not good, but it was more OK than being unusable.

One of the most important skills a tester can develop is the ability to gather information about what’s important. It’s impossible to test everything, so figuring out what matters—and what doesn’t—is a strong predictor of success.

DL: As a manager, have you felt the need to do hands-on testing with your teams? If so, what were the goals?

CP: I’m a big fan of managers testing. As an engineering manager I’ll make better decisions when I know more about what the system


StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.