The cost of a bug: why testing before release costs far less than fixing it after

Why a bug gets more expensive at every stage

Each stage of a project rests on the one before. A mistake in the requirements flows into the design, the design into the code, and more code is built on top of that code. The longer a bug lives in the project, the more work is built on it and the more has to be redone.

Here is how the cost of fixing the same mistake changes, taking a wrong rule for calculating a discount as an example:

1. In the requirements: correct one sentence in a document.
2. In the design: redraw a few screens and get them approved again.
3. In development: rewrite the code and everything already built on it.
4. In testing: reproduce the bug, fix it, test again and make sure nothing nearby broke.
5. After release: all of the above, plus tracing the cause on the live server, correcting real customers' data and rushing out an update.

There is a human factor too. During development, a programmer has the context fresh and fixes a bug quickly. A month later they're working on something else and need time just to make sense of their own code.

The hidden costs after release

The direct cost of the fix is only the visible part. If the basket or an enquiry form breaks, the business loses money every hour until someone notices, and that often takes a while.

Then the support load grows: emails, calls, messages on social media. Every request takes time, and some unhappy customers never write at all. They simply don't come back.

For mobile apps the price is even higher. A fix has to pass review in the App Store or Google Play, and users have to update the app, so the version with the bug stays on people's phones for a while. Low ratings and angry reviews remain visible in the store and influence whether new users install the app.

Finally, emergency fixes stop planned work. The team puts a new feature on hold to fight the fire, and the release you were counting on slips.

Kinds of testing, in plain words

Testing isn't a single activity but a set of different checks, and each one catches its own kind of bug:

• Manual exploratory testing. A tester uses the product as a customer would, tries unusual actions and looks for what nobody anticipated in the scenarios.
• Regression testing. Features that already work are checked again after every change, so the new doesn't break the old.
• Unit tests. Automated checks of individual pieces of code, such as the price calculation or the validation of form fields.
• Integration tests. These check how the pieces work together: the app and the database, the website and the payment service.
• End-to-end (E2E) tests. They automatically walk through a whole user journey, from logging in to paying, in a real browser or app.
• Testing on real devices. An emulator won't show you everything: a weak processor, an unstable connection, the quirks of a particular screen.

Automated tests check what is already known, quickly and cheaply, after every change. People find what nobody thought to automate. You need both.

Quality is a process, not a final check

Quality assurance (QA) and testing are often confused. QA is the process that prevents bugs: how requirements are written, how code is reviewed, what gets tested and when, and what "done" means. Testing is part of that process: the specific checks that find bugs in a product that already exists.

Quality is built in from day one. It starts with acceptance criteria, the specific conditions a feature must meet to count as finished. For example: "the form can't be sent without a phone number and shows a clear error message". They are written before development, so the developer, the tester and the client all picture the same result.

From the criteria, testers write test cases: step-by-step scenarios with an expected result. They become the basis for regression testing and make sure nothing important is forgotten before a release.

The last step is automated tests in the release pipeline (CI/CD). Every change goes through the checks automatically, and if any of them fails, the version doesn't reach the live site. Every bug that is found also gets its own test, so it can't come back unnoticed.

The bottom line

You can't undo a bug, but you can find it while it's still cheap. The earlier acceptance criteria, test cases and automated tests appear in a project, the fewer unpleasant surprises reach your customers and your budget.