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.

Image for post
Image for post
Photo by Fabian Blank on Unsplash

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.

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.

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.

Written by

Today the world doesn’t need your fear or your worry. Now, more than ever, it needs the best version of you!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store