Why QA Engineers are Needed

In my company, software engineers vastly outnumber QA engineers. My team has about ten people- all software engineers. We had one QA engineer assigned to us, but he had to take some time off work, and when he returned, he was assigned elsewhere. To me, this feels like a problem. Why?

Mainly because they have a different view. A software engineer doing testing has a conflict of interests. We want to build software and more than that, we want to know how it works. QA engineers just care that it works. Well. They want to know how to make it work from a user's point of view.

Having a different view is a huge difference. A different view is vastly under-appreciated. We've seen over and over in life how a conflict of interest can completely bias someone. This occurs even though they know about the conflict and believe they've taken it into consideration. Over and over we learn that we have too much confidence in ourselves and too little appreciation for how our circumstances bias our point of view. This area is a blind spot.

There are two reasons to have a team. One is that more workers can do more work. The other is that more viewpoints can see more about the same thing. This second point can be much more valuable than the first, if appreciated and utilized.

In fact, this is where the value of "pair programming" (an "agile programming" technique) comes from. Partly, while one person is typing and designing code, the other is free to keep thinking about the ramifications, the side effects and use cases. And partly, different people simply have different views. Two people coding see much more much faster.

Another way we take advantage of this is in code reviews. Unfortunately, we try to do everything as quickly as possible. Again, this gives us a conflict of interest. We often skip over details in a code review. We don't make lists of all the things that have to happen and then see if they do. We don't consider all the use cases during the code review. We usually catch a few of these, so code reviews are valuable, but again, our blind spot about our conflict of interest diminishes their value.

What's great about great QA engineers is that they have a whole different outlook, including different responsibilities. I've been a software developer for many years. Can I test? Certainly. Can I emulate a good QA engineer? To be honest, not that well. I've known some great testers- they're amazing at creating interesting user scenarios. My team has created a bunch of user scenarios, too, but I doubt we've done a good job at it. We simply have a lot of other things on our minds.

A big part of it is that we're still paid, and rewarded, for creating the softare. Recently I spent a week testing, but all the time my mind was also occupied with creating test software and figuring out what wasn't working. I came across a number of small bugs that I put out off till "later" because I was working on a particular bug. If I stick to it, I'm sure I'll improve, perhaps even master it, but doubts surface of whether I'll be as valued at bonus time. My mind imagines that I'll be wasting some of my talent. Can I put these aside? Certainly. Can I be sure they aren't influencing me? Not with what I've learned about perspectives and blind spots. I can feel certain, but wisdom tells me not to trust the feeling. (Plus we're struggling to hire software developers- why not enlarge the pool of applicants by hiring great QA engineers to do testing?)

If I were to become a good tester, I think the main thing I'd do differently is not fix bugs, not know how the code works, and not even automate tests- even that takes away from the user's view of the product, making me worse as a tester.

In our culture, we value skills and knowledge. Perspective is the key differentiator between people, but we ignore it, almost completely. We're ignoring it now.