Developers Are Not QA Testers

When a company says “we can’t afford a QA department”, what they’re really saying is, “we accept that our software will be infested with bugs, and quality is not important to us.” When they compound this basic error by saying, “the developers will just have to do their own QA”, they prove that they have no respect for developers or QA people, and you shouldn’t work for such a company in either capacity.

(Of course, a company like that isn’t about to hire any QA testers, so you folks haven’t got the option of working for them. And I’m not a QA tester, I’m a developer. So the rest of my advice is pretty much aimed at fellow devs — but that doesn’t mean I don’t respect you QA folks. Seriously, y’all deserve a lot more respect than you get, and I love it when you make my life easier by finding my bugs for me.)

The skills, talents, and basic mindset that make a good developer are entirely different from the ones that make a good QA person. Asking one to do the other’s job is a mistake as fundamental as expecting graphic designers and accountants to swap places. Let me explain:

Developers hate repetition. We hate having to repeat anything more than once or twice; that’s why some of us become developers in the first place: because we can write programs that automate repetitive drudgery, and hence banish it from our lives.

It’s not just repetitive tasks, either. A good developer will also have a strong aversion to repetitive code and data. If two procedures differ by only one or two minor details, a good developer will combine them into one, and parameterize it, or otherwise figure out a way for the machine to make the decision. (A poor coder, by contrast, will produce “copy-and-paste code” that’s scorned by more advanced devs, because it’s more brittle as well as being less elegant.) If data must be stored somewhere, the prevailing wisdom is to keep it in just one place — “Don’t Repeat Yourself” is the maxim.

But a good QA checker has to deal with repetition all the time. It’s a fundamental part of their job. Run this test plan — this particular series of actions — over and over again, on each of the platforms we need to test on. Log every step of it, so that if something does go wrong, we can reproduce it.

Then, once the coder has checked in the changes that (hopefully) will fix the bugs you found… do it all over again. Just the exact same way. On every platform.

This is a coder’s nightmare. A developer’s natural response to this situation is to write some kind of automated QA-testing software. Of course, that software itself will then have to be checked for bugs before you could possibly rely on it… and you can’t trust your software to find its own bugs.

In the absence of such software, asking a developer to do bug-checking means asking them to do something that goes against their very nature. You can force them to do it, but they’ll never be really good at it.

Of course, all of that is totally leaving aside the obvious point that asking someone to find the flaws in their own work means asking them to see past their own mental blind spots — a developer’s test plan will be based on the same assumptions as their code, without the coder even realizing it. And that’s to say nothing of the obvious implications once you put the human ego into the picture. Human beings are flawed, and too many see “find the bugs in your own code” as equivalent to “show me all the ways you suck”.

Don’t ask a developer to do QA. Development and QA testing are fundamentally different disciplines, with completely different skill-sets and personality requirements. A developer can no more cover for a QA tester than a QA tester could fill in for a developer.

And if you’re a developer at a company that wants you to do your own bug-checking? Your employer thinks what you do is so similar to bug-checking that you’ll be good at it. They think they can cut corners on quality, and pay you one salary to do two jobs at once (including one job that it is in your nature to hate). If you can’t make them see reason, it’s time to brush up your résumé.

3 Comments