QA As A Crutch

May 31, 2012

Would quality be better if there were no Quality Assurance people? Let’s face it, most engineers abuse QA. They write a bunch of crap they’ve never tested, declare it’s done to much fanfare, and throw it over the wall to QA while they sit back knowing it’s going to take QA at least a day or two to start writing up bugs – more than enough time to get in some solid games of foosball. Furthermore, once they have *said* they are done, the pressure is off of them, and on QA to find them, at which point the engineer can sit back and pick and choose what they feel like fixing under the guise of “triage”.

Whether this occurs or not is dependent entirely on how much the engineer cares about there being bugs in the system. Fact is, most engineers don’t really care, using the rationale that bugs are simply by-products of developing software, and that having a certain number of bugs should be acceptable. Furthermore, some bugs are minor, and should be de-prioritized in favor of higher priority bugs, so really there are some bugs that will never be fixed by virtue of responsible prioritization. This all sounds reasonable and defensible, doesn’t it? Heck, most people reading this would say, “Hey! That’s the process we use!” Yeah, it is – and your engineers are gaming the system.

The truth of the matter is that these types of engineers are typically lazy bastards and are unaffected by the presence of QA — they will do whatever they feel like, largely because they are allowed to get away with it. If you work with these types of engineers just figure out what they did to get such a sweet deal, and get career tips from them. They’re probably on a fast track to management. The engineers who benefit most from not having QA are those who are not lazy bastards. These are engineers who take pride in their work, and don’t want any bugs in their system, but who make honest mistakes. Without QA, these engineers get better as they develop the self discipline required to thoroughly test their work before declaring it done to anyone. In terms of bang for buck, you’re best off keeping your novices away from QA so that they learn how to produce quality code on their own.

Settings

I would like to point out that if we work together today, or have in the past, my opinions may or may not have been influenced by working with you. Most likely they have been, but I have to say that to avoid offending people. You're so vain. I bet you think this site is about you.