The Balance Between Prevention and Inspection
One of Deming’s 14 principles states that we should cease dependency on inspection. Does this mean that we should try to eliminate testing in favor of prevention?
Machiel Groeneveld tweeted about (automated) testing, he argued that tests fit Deming’s definition of inspection.
I replied that, when tests are being developed and executed at the same time as the software, you could see that as a form of “build quality in” instead of inspection. That leaves room for interpretation, as Machiel instantly noted. For instance, does that only include developer tests? Or do tests from a separate tester (in the same team) also qualify as built-in quality?
Lars Vonk chipped in that software tests should not be primarily aimed at quality, but as a tool to prevent bugs and as a process improvement tool.
Donald Reinertsen then introduced an economic perspective on the situation. His argument is that there is an economic tradeoff between prevention and inspection. If inspection (and the associated rework) is economically more feasible than prevention, than you may have a legitimate case for inspection, despite Deming’s principle.
Deming’s underlying assumption is that prevention is always cheaper, because to prevent an error from happening again is a one-time investment, while inspection and rework is a recurring cost. An interesting observation is that automated tests may violate this assumption. An automated test lowers test execution cost significantly, maybe even more than the cost of preventing bugs. Reinertsen uses the example of the spelling checker: experience tells us that inspection with a spell checker is cheaper than preventing spelling errors in the first place.
If you or your team are moving more towards prevention instead of inspection, that’s a good thing. But keep in mind that one day, the cost of more prevention might outweigh the cost of inspection and rework. As soon as you hit that point, look for more valuable alternatives to improve your process.
Hi there Martin,
Of course, you’re right. Prevention is always better than inspection and rework. But it also states an impasse (if this is also an english term, but you’re Dutch, so you probably understand what I mean). Too much prevention will slow down to a point where prevention will undermine progress within the project. In my point of view, there’s only one possibility: more prototyping and short lines to the end users. When it comes to testing, the only real important part is the acceptance test by the end users, for two reasons: first the users will test if the software checks with their demands, second, the users will have the sheer feeling that they matter.
What’s your thought on this? And have you ever encoutered a project where testing didn’t add value to the product?
Regards and thanks for the post!
Douwe Pieter