The cost of faults escalates as we progress from one stage of the development life cycle to the next stage. A requirement fault found during a review of the requirement specification will cost very little to correct since the only thing that needs changing is the requirement specification document.

If a requirement fault is not found until system testing then the cost of fixing it is much higher as the requirement specification will need to be changed together with the functional and design specifications and the source code. After these changes some component and integration testing will need to be repeated and finally some of the system testing. If the requirement fault is not found until the system has been put into real use then the cost is even higher since after being fixed and re-tested the new version of the system will have to be shipped to all the end users affected by it.

Furthermore, faults that are found in the field (i.e. by end-users during real use of the system) will cost the end-users time and effort. It may be that the fault makes the users’ work more difficult or perhaps impossible to do. The fault could cause a failure that corrupts the users’ data and this in turn takes time and effort to repair.

The longer a specification fault remains undetected the more likely it is that it will cause other faults because it may encourage false assumptions. In this way faults can be multiplied so the cost of one particular fault can be considerably more than the cost of fixing it.
The cost of testing is generally lower than the cost associated with major faults (such as poor quality product and/or fixing faults) although few organizations have figures to confirm this.