Quality, and the cost of a bug found late

The whole economic case for QA rests on one pattern: the later a bug is found, the more it costs. A defect caught during design costs almost nothing to fix; the same defect caught by a customer in production can cost a fortune. Understanding this — really understanding it — is what lets a QA argue for testing time, prioritise sensibly, and explain to a sceptical manager why finding bugs early is not a delay but a saving. This lesson is the cost of quality, and what "quality" even means.

What "quality" actually means

"Quality" sounds vague, so pin it down. Quality is fitness for purpose — does the software do what its users actually need, reliably, under real conditions? Note two things this definition includes:

It is about the user's need, not the specification on paper. Software can match the spec perfectly and still be poor quality if the spec was wrong or the real user's world differs (the spec said "wifi", the user is on 2G).
It includes reliability under real conditions — not just "works when I try it once on my machine", but works on the user's cheap phone, on a bad network, when they do the unexpected, at 9am when everyone logs in at once.

So quality is not "no bugs" (impossible) — it is "does the job it needs to, well enough, for the people who use it". A QA's job is to find the gaps between that and reality. There are two useful lenses: validation ("are we building the right thing?" — does it meet the real need) and verification ("are we building the thing right?" — does it match the spec). A QA does both, and catching a validation gap (the feature works but solves the wrong problem) is often the most valuable find of all.

The cost curve: early versus late

The central fact, sometimes called the "cost of change curve": the cost of fixing a defect rises steeply the later it is found. Roughly:

Found during…	Relative cost to fix
Requirements / design	tiny — change a sentence
Development	small — a developer edits code they are already in
Testing (QA)	moderate — a developer context-switches back to fix it
Production (a customer hits it)	large — support, investigation, emergency fix, redeploy
Production, and it caused damage	huge — lost money, lost trust, sometimes lost customers

The exact multipliers are debated, but the shape is not: each stage later is several times more expensive. Why the steep rise? A bug found in development is fixed by someone who has the code in their head, right now, with no one affected. A bug found in production has already reached users, needs investigating (which build? which users? what data?), a fix, testing of the fix, an urgent deploy, and often cleanup of the damage it did — plus the reputational cost. QA's value is moving bug discovery left on this curve — from the expensive right-hand side to the cheap left.

The cost is worst when money is involved

For the money-handling apps this course targets, the right-hand side of that curve is especially brutal. A cosmetic bug in production is embarrassing; a transaction bug in production can:

Move real money wrong — charge a customer twice, credit the wrong account, lose a top-up, let a balance go negative. That is not a support ticket; it is money the company must find and refund, and trust it may not recover.
Scale silently — a transaction bug does not hit one user; it hits every transaction of that kind until someone notices, so by the time it is found it may have affected thousands.
Attract scrutiny — money bugs draw regulators, auditors and angry customers in a way a broken layout never does.

This is why the money-and-transaction-flows testing gets a whole lesson, and why a QA on such a product tests those flows the hardest: it is exactly where "found late" costs the most. Finding a double-charge bug in testing versus in production is the difference between a five-minute fix and a company-wide incident.

What this means for how you work

The cost curve has practical consequences for a QA:

Get involved early. The cheapest bug to fix is one found in the requirement — before any code exists. A QA who reads a ticket and asks "what should happen if the payment succeeds but the network drops before we get the response?" has found a bug for the price of a question. This is "shifting left" — bringing testing thinking to the earliest stage, not just the end.
Prioritise by cost-if-missed. You cannot test everything (the risk-based-testing lesson), so spend your effort where a missed bug is most expensive — the money flows, the security, the data integrity — not where it is cheapest (a cosmetic tweak).
Argue for testing time with the curve. When someone says "we don't have time to test", the honest answer is: testing time is cheaper than the production incident it prevents. The cost curve is your argument, and it is a strong one.

The instinct to carry: every bug you find in testing is a bug that did not reach a customer at many times the cost — and the ones worth finding most are the ones that would have cost the most if missed. That is not a delay to shipping; it is what makes shipping safe.

Check your work

What quality is. Fitness for purpose — does the software meet the user's real need, reliably, under real conditions (cheap phone, bad network, unexpected use, load) — not "matches the spec" and not "no bugs". Validation (right thing?) and verification (thing right?); a QA does both.

The cost curve. The later a defect is found, the more it costs — tiny in design, small in dev, moderate in QA, large in production, huge if it caused damage. Each stage later is several times more expensive.

Why the rise is steep. A production bug has reached users and needs investigation, a fix, re-testing, an urgent deploy, and damage cleanup, plus reputation — versus a dev-stage fix by someone already in the code.

Money makes it worse. Transaction bugs in production move real money wrong, scale silently across all transactions, and attract scrutiny — the most expensive place to find them, so test money flows hardest.

How you work. Get involved early (shift left — the cheapest bug is found in the requirement), prioritise by cost-if-missed, and use the cost curve to argue for testing time (cheaper than the incident it prevents).

Practice

Take a bug you know of (from any product) and place it on the cost curve at the stage it was actually found; estimate what it would have cost if found one stage earlier or later.
For a payment feature, describe a transaction bug and trace its cost if found (a) in testing vs (b) in production after affecting 5,000 users.
Distinguish a validation failure (right thing?) from a verification failure (thing right?) with an example of each.
Read a real requirement or ticket and find one question whose answer is a bug found "in the requirement" — the cheapest kind.
List three features of an app ranked by cost-if-a-bug-is-missed, and argue where a QA should spend most effort.
Write the two-sentence argument you would give a manager who says "we don't have time to test this release".

Official documentation

ISTQB — Foundation syllabus (cost of defects) — The cost-of-quality and shift-left principles, formalised.
Ministry of Testing — Community and resources — Practitioner writing on quality and the value of testing.
Google — Testing on the Toilet / Testing Blog — On building quality in early.

Next: test levels and types — unit to acceptance, functional to non-functional.