20.4. When to Do Quality Assurance

As Chapter 3 ("Measure Twice, Cut Once: Upstream Prerequisites") noted, the earlier an error is inserted into software, the more entangled it becomes in other parts of the software and the more expensive it becomes to remove. A fault in requirements can produce one or more corresponding faults in design, which can produce many corresponding faults in code. A requirements error can result in extra architecture or in bad architectural decisions. The extra architecture results in extra code, test cases, and documentation. Or a requirements error can result in architecture, code, and test cases that are thrown away. Just as it's a good idea to work out the defects in the blue-prints for a house before pouring the foundation in concrete, it's a good idea to catch requirements and architecture errors before they affect later activities.

Cross-Reference

Quality assurance of upstream activities requirements and architecture, for instance is outside the scope of this book. The "Additional Resources" section at the end of the chapter describes books you can turn to for more information about them.

In addition, errors in requirements or architecture tend to be more sweeping than construction errors. A single architectural error can affect several classes and dozens of routines, whereas a single construction error is unlikely to affect more than one routine or class. For this reason, too, it's cost-effective to catch errors as early as you can.

Defects creep into software at all stages. Consequently, you should emphasize quality-assurance work in the early stages and throughout the rest of the project. It should be planned into the project as work begins; it should be part of the technical fiber of the project as work continues; and it should punctuate the end of the project, verifying the quality of the product as work ends.