“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. – W E Deming“. This above quote has been making rounds in the technology circles implying (or mostly misunderstood as) post-code Software Testing is just cursory or not important.
I’m pretty sure that Deming told those words in the context of hardware manufacturing quality, more specifically, for the manufacturing of car parts. Software differs from a mechanical, manufactured part in that you cannot ‘see’ the end-product to inspect, unless you perform various acts on it to make sure that it works as expected. Even these results are ‘see-believe’ and not a proof that Software is working as expected. If such is Software complexity, how can a ‘quality built-in during development’ be a sufficient condition to raise our confidence before the product hits our customers? Note that I am not saying that one should not aspire to build quality in in earlier stages. They can, but those attempts are not sufficient for our confidence levels however hard we try, because we identify defects or deviations in a finished software product that are not detectable in earlier stages.
Deming’s saying should not be applied out of context and used as an excuse to downplay/avoid Software Testing that is done after the product is built. It is late in the cycle to test post-code alright, but that should not be the reason for avoiding Software Testing altogether or downsize it to some playful ‘exploratory testing’ with no proper planning in place. And no, automating the tests is no substitute to context-sensitive, thorough Software Testing.
In today’s environments of microservices, cloud computing, diverse infrastructure and deployment situations, and complex software dependencies, it would be unimaginable to take care of all the situations and possibilities upfront before the product is fully built and put to test. Many of us would be warily aware of the recent outages that happened because of performance, security, storage, maintenance and various types of issues. I would argue that if sufficient thought had been put in solution testing for these complex scenarios, much of the heartburn and business losses could have been avoided. In one instance, in spite of the engineering team warning that the product be tested before release, the management went ahead and released the product without testing stating that it can be taken care of as required. The organization is now facing a nightmare situation.
So, let better sense prevail, and sufficient emphasis and importance be accorded to Software Testing.