Why Developers Shouldn't Perform Software Testing - A Rebuttal

Take a minute and read the following 2-pager entitled "Guest View: Why developers shouldn’t perform software testing".

Man, I tried to like this article because the author, Martin Mudge, clearly knows that businesses who undervalue quality by trying to eliminate testing through simply shuffling the traditional testing task to developers are making a huge mistake. Unfortunately he begins by making an assertion that testing overburdens a developer which at face value is complete nonsense. If you feel overburdened, it is a timeline issue and that is true no matter WHAT the nature of the tasking is.  So his assertion of “one the most important” contributing factors being overburdening the developers is massively flawed. It gets immediately worse from there because his second point is about time constraints. 

Mr Mudge just gets so much wrong. What he really should be shooting down is the idea that testing, as a cost-center not as a task, can be eliminated by having your product center carry that specific task load instead. But if that’s your company’s opinion of the value of testing, then your developers aren’t going to want to be handed that. It doesn’t matter if it is testing or any other related task, if you portray the work as low-value and then ask someone who thinks of their work as high value to add it to their plate, it is naturally an insult. It all begins with management’s attitude. However, given that Mr Mudge’s company, BugFinders, sells software testing as a service, you may surmise that he’s not in the business of contradicting that point of view but exploiting it to earn a living as an outsourced contract cost center. Of the 5 points their website makes about the value of their testing service, it is very telling that the 5th point is: "Control testing costs by setting a fixed budget”. 

The bottom line is that bugs are inevitable and no amount of testing budget will 100% prevent them, even major bugs, from escaping into the wild forever. But that’s okay. Failure is okay. You should seek out failure. Everybody should visualize it, as early in the process as possible, and start thinking about how to address it. Failure should be embraced, understood, and anticipated by all team members. The value of dedicated QA Engineering is giving professionals the job of specializing in looking for, characterizing, reporting, triaging, and tracking all avenues of failure in your product and then reacting to that organizationally with sober consideration. These avenues of failure can be observed failures (bugs) or potential failures (risks). But there are many things that can lead to handling bugs or risks improperly which happens the instant your priorities are no longer aligned underneath overall quality. 

Here’s a great episode of Freakonomics Radio that talks about failure.

Everybody’s priorities should be the same but their role dictates how they carry out their work with respect to those priorities. Therefore if quality is anyone’s priority, it MUST be everyone’s priority. You can’t know if you’re meeting your quality priority without testing your work. That’s why really smart companies are reducing the number of dedicated QA Engineers but making everyone a tester. They’re buying into W. Edwards Deming's principle of eliminating a lengthy inspection process at the end of a production cycle and front-loading quality by making it everyone’s concern (thus reducing the overall cost of achieving higher quality). That doesn’t mean eliminating inspection. Instead that means don’t rely on dedicated inspectors only for ensuring product quality. That means elevating testing to an unmistakably high-value activity and expecting every high-value contributor to master it in the context of their role. That means more inspectors, not fewer, conducting more inspections more frequently. That means adding more perspectives and questioning more assumptions. In the end, my opinion is very clearly expressed in the title of this blog: Everybody Tests.