In the recent past, our organization reviewed the software quality planning for a very large, complex software implementation for a large organization. The implementation was being performed by a well-known consultancy, one which had successfully completed multiple such implementations in the past. The initial overarching project planning document was approximately 300 pages long; not more than 5 pages were devoted to testing and software quality.

Now, in all fairness, the document did refer to future planning tasks for testing cycles that were scheduled to be written. And some of them were, eventually.

The main point here, though, is one of emphasis. If, at the current stage in the maturity of the industry, software quality attracts so little attention at the beginning of a large project, and one implemented by a respected and successful organization, then it is clear that the case for investing in software quality has not been made to the industry.

Now, you might look at the recent history of the field, and conclude that all the companies that have been building their own software and have deployed with what, on paper, looks like insufficient testing, have “gotten away with it.” The economy has not faltered (at least, not because of software defects), and there haven’t been an overwhelming number of reports in the press about companies stumbling due to major glitches in their software. NIST, the National Institute for Standards and Technology, recently pegged the cost of inadequate software testing at $59 billion. Not chump change, but, you might argue, an acceptable cost in a trillion-dollar economy.

This is looking at it in the wrong way. Software quality investments should be looked at in the same way we look at insurance policies, because that is essentially what they are – mechanisms for reducing risk to the enterprise. Just as no individual can afford to drive without insurance because the personal risk is too high (even though society may be able to absorb the costs of the uninsured), no organization can afford to short on software testing – because the risk is too high. Anyone who views this from the perspective of organizational risk will “get” it – and the argument that the status quo has worked in the past falls flat from a risk perspective, because statistically, the longer one goes without a major failure, the likelier a failure becomes, not the opposite.