Is Software with Zero-Defect Quality possible?

The expression of a zero-defect quality has been coined by Philip B. Cosby in the early 1960s. TQM (Total Quality Management) as well as Six Sigma consider a zero-defect production as desirable objective.

In software development zero-defect quality would mean that – depending on the definition, what a defect is – all explicit (described in a requirements specification) and all implicit requirements (e.g. typical expectations of non-functional characteristics as robustness, usability, etc.) are fulfilled. Due to the size and the complexity of software, but often also as a debt of a fuzzy or incomplete requirements specification, it is not feasible with reasonable expenses to verify that software is free of defects.

However zero-defect quality should be understood as an ideal goal. The issue is the common understanding of quality by all persons involved in software development. Software defects must not be considered as ‘normal’, i.e. a defect rate greater than zero is not acceptable. This should not lead to punishing developers who are responsible for defects, but better to a general root cause analysis for each defect to find out by which measures similar defects can be avoided in the future. This is the key for a continuous improvement of all areas related to software development, which definitely helps to approach to a zero-defect quality – even if it is not possible to reach it.