Delusion of quality and the destruction of deadlines.
“A splendid idea!” thought Ben the Project Leader. It is without a doubt a sensible idea to divide the budget of development in a way that testing can be bought as a service only when we need it.
We run the first testing round for the release candidate number one. After we get the results, we fix the bugs, and the second round will be used to verify that everything went as planned. Two rounds of testing are just perfect!
A surprising number of software projects use Ben’s style. The approach is ultra sensible as long as:
- We design no new use cases or requirements or stories.
- The product does not change in any way other than bugs getting fixed.
- The bug fixes do not break anything else.
In projects like this, it is inevitable that the scheduling fails when we introduce testing. The original plan just happened to be unrealistic.
Professional testing done too late discovers more bugs than expected. Much more. Always.
Then the deadlines become unreachable because fixing that amount of bugs takes an unexpected amount of time. Usually, on the first testing round, we also come up with test ideas that we cannot execute. Some of the bugs prevent reliably testing the functionality they infest.
During the verification round, we again discover loads of new bugs just because the testers now know the product and because some fixes let us act on our previous testing ideas.
And of course, the probability of flawless bug fixing without any regression is next to none as well.
Ben’s plan is great if the quality of our product is exceptional already. For every regular project, however, it just won’t work. Testing too late will destroy those deadlines.
So don’t be Ben, don’t ruin a good project with an unrealistic delusion of quality.
