It is known as the 1:10:100 Rule: the cost to fix a defect increases exponentially the later in the development lifecycle that it is identified.

Photography by Absolutwade.

• A defect caught in requirements phase costs a factor of 1 (1x) to fix.
• A defect caught in construction costs 10 times as much as in requirements.
• A defect caught in production costs up to 100 times as much as in requirements.

In this context it makes sense to define the test scripts as early as possible, during the requirements definition.

Or, as Terry put it into a mail to me:

Most companies currently decompose requirements into test cases for system testing during the construction phase. If they would simply move this same effort forward to the requirements development and physical design phases, they could save a lot of money!

However, I am wondering how current techniques, and tools are affecting this. The costs of creating testable applications (proof of concepts, prototypes etc) to use as feedback mechanisms are dropping, so I wonder if the 1:10:100 factors are still holding true.

Of course for large complex systems it will still hold, but for smaller business apps, I am not sure. But incorporating the test cases already with the requirements definition is always a good idea. End of course, making a change in a design documens is most of the time cheaper than changing a running system. But if those numbers are still exponential?

I wonder.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - The 1:10:100 Rule is a post from: Project Shrink.