Every team that treats testing as the last box before launch eventually meets the same bug: discovered in week eleven, rooted in a decision made in week two. The bug was always going to exist. The only thing the process decided was what it would cost.
A bug's price is set almost entirely by when it is found.
The rule of thumb
The cost of fixing a defect rises sharply with how late it is found. The exact multiplier is argued over; the direction has never been in dispute.
What the same defect costs, by when you catch it
- In the requirements — a conversation.
- During design — a revised screen.
- While the code is being written — a fix the developer makes with the full context still in their head.
- In a testing phase months later — archaeology.
- In production — an incident, a support queue, and a little of your users' trust, which is the one currency that does not refund.
Why end-of-project testing fails
The problem with a QA phase is not that testers find too little. It is that they find the wrong things too late.
Serious defects that surface at the end are rarely typos. They are structural. A flow that cannot handle a cancelled payment. An assumption about users your data model cannot express. By then the decisions underneath have hardened, and the honest fix is competing with the launch date.
The testing window sits at the end of the plan, which means it is also the project's buffer — and when development runs long, it is the buffer that gets eaten.
Fixes made under that pressure are exactly the ones that break something else, which is how a two-week QA phase quietly becomes the least effective testing a project will ever get.
What testing throughout actually looks like
None of this is an argument for more process. It is an argument for earlier evidence.
Write acceptance criteria as testable statements before the feature is built, so "done" stops being a matter of opinion. Grow automated tests alongside the code and run them on every change, starting where money or data moves. Do a real-device pass before each release instead of one heroic sweep at the end. And monitor production, because the last tester on every product is the real world.
How we work
Our QA engineer joins at the design review, not after the build
Half of what they catch never becomes a bug at all — it gets removed from the design before anyone writes it.
Testing at the end answers only one question: is it too late to fix what we find? Testing throughout answers a better one: is this still on course? Quality is not a gate a product passes through in its final fortnight — it is a thread that runs the length of the build. If you change one thing after reading this, make it the calendar: move whoever owns quality on your team into the design review for the next feature, before a line of it is written. It costs an hour, it is the cheapest intervention available, and you will be able to measure it by what never reaches the bug tracker.