Software Sucks Because QA and Testing are Underpaid and Misunderstood

Everybody who hires in the software industry complains about how hard it is to find good QA people. It’s no wonder, considering how little we respect them and how little we pay them.

In the past couple of years I’ve heard a lot of people go on about how testing and quality should be the whole team’s job and therefore the role of a test or QA person should not even exist in the first place. It should be absorbed into the daily diligence of engineering and design.

This attitude is symptomatic of the general disregard and disrespect for QA that I see everywhere and which is ruining our software. It assumes that quality assurance and testing are not special skills that require special training, but something that anybody can do, on the side. Anyone who understands and respects testers knows that it takes a special kind of brain to be a great tester. A great tester has a criminal mind, sometimes a dash of sadism, a contrarian bent, and a methodical, analytical passion that drives them to imagine every possible human trick or foible that could make your product fail.

A great tester is proud to break things. A developer can rarely be so ruthless with the product.

I absolutely agree that every person on the team takes some responsibility for testing. Engineers should write unit tests and submit bugless code to the best of their abilities. Designers should have their perfectionist eyeballs on every day’s build, crying over misaligned pixels and miscoded animations. But unit tests and design fine-tuning don’t replace the kinds of hoops a great QA team makes an app jump through.

A great app does not work perfectly for most people most of the time, which is what you will get (if you are lucky!) with the most well-intentioned amateur general testing. A great app works perfectly even at the edges, and when it can’t give the user exactly what she wants, it fails with grace and friendliness because the failure is known, and designed.

Another factor contributing to the general disregard for QA comes partly from the practitioners themselves. Quality Assurance metrics very rarely go beyond the specification or the performance benchmark. If you are really good, your QA team cares about processes and documentation. As Umair Haque noted in his article about Twitter’s Demise, the end user’s emotional reaction or the online community’s culture is almost never considered in the context of quality assurance.

The main reasons for this are twofold. On one hand, we have a hard time prioritizing anything that can’t be measured by a number or easily checked off a checklist. (I’ll have to write a follow-up article on this called, Software sucks because we only care about what we can measure.) While this is sad enough, what is even sadder is that when QA practitioners do care about user emotions or usability in general, they are almost never allowed to do anything about it. In most cases, the role is seen as such a lower caste to the rest of the development team, that any comments from QA on usability are simply ignored.

Testers are power users on the inside of your team, but nobody listens to them because nobody respects them. Testers know the ins and outs of your application better than anyone else. They know the tricks, the shortcuts, the sandpits, and the stress points. But most of the time, nobody listens.

One of the ways we show that we don’t respect QA practitioners, manual testers, and test engineers is that we don’t pay them very well. Automation has become central to testing, especially in the mobile app world. You often meet test engineers who want to be front end engineers, but you rarely meet a front end engineer who wants to be test engineer. You might think that the reason for this is because it’s more fun to build the front end than to set up test automation or to play Sherlock Holmes against a GPU overload, but you would be wrong. Testers have a different idea of fun than you do. The reason great test engineers abandon the field for front-end development has everything to do with pay and prestige.

I have seen and run teams where QA was respected and heard. These teams make better software than teams where QA is an afterthought. These teams make better software than teams where QA’s sole job is to find bugs in the code. If you want to get the most out of your QA brains, here are three tricks I have used with great results:

1. Include the QA team in all phases of development as an equal partner. Send them to user testing debriefs, include them in workshops, listen to their feedback on product concepts. Listen to them, period. If your QA people are not sharp enough to give useful feedback, it’s not because QA people don’t have those kinds of insights. It’s because you hired the wrong QA people.
2. Give the QA team more responsibility. In one of my highest-performing teams, QA was responsible for approving acceptance criteria on all user stories. The QA lead was release manager and had final say on whether the build went to users or not.
3. Make the QA lead the equal of the Design and Dev Leads in your hierarchy. Give the QA Lead line management over the QA team. It is weirdly commonplace for the QA team, including the QA Lead, to be line managed by the Dev Lead. Even if it doesn’t usually cause any real earth-shattering problems, it’s philosophically and politically wrong. It’s like Wall Street being the boss of the regulators. It’s like the fox being the boss of the chicken coop.

There are a lot of improvements we can make in how we build software. Some of them are easier to address than others. Our misunderstanding and disrespect for QA and testing is one of the most widespread and most deeply damaging of the issues we need to fix.

P.S. I know I am conflating testing and QA. I look forward to you correcting me, especially my friends in the field. I know it’s a bit like mushing UX and Design into a synonym lump, but I didn’t feel like the fine distinction between the two was relevant to the overall point.