Bug Cost Calculator

The conventional progression is roughly 1:10:100 from requirements to development to production. The exact multiples are contested; the direction and the order of magnitude are not.

Studies from the 1970s and 1980s whose methodology has been questioned for decades — small samples, inconsistent definitions of a defect, and original data largely unavailable for scrutiny. Treat them as a rule of thumb, not a finding.

Because the fix is the smallest part. Triage, reproduction, a hotfix, an unplanned release, customer communication and the interruption to whatever the team was doing all attach to it and none of them attach to a bug caught in development.

Moving defect detection earlier — better requirements, review, automated tests, static analysis. The business case is exactly the gap between the phase multipliers, which is what this calculates.

No. Testing has a cost and the return depends on how many defects it actually catches and how expensive those defects would have been. A large investment against a few cheap defects does not pay back.

No. A defect nobody encounters costs nothing to carry, and fixing it carries regression risk. The cost of the defect, not its existence, is what should decide.

Small samples, inconsistent definitions of a defect, original data largely unavailable, and results generalised far beyond their context. Several careful reviews have found the widely cited numbers difficult to trace to anything solid.

The direction almost certainly is, for a straightforward reason: a production defect drags triage, reproduction, a hotfix, a release and customer communication behind it, and a development-time defect drags none of those.

The one caused by an unclear requirement, because it costs nothing to prevent and can be expensive to discover. Requirements defects are also the most likely to survive all the way to production.

Depends entirely on what they catch and how often they run. A suite catching real regressions on every commit usually does; a suite of brittle tests that fail spuriously costs more than it saves.

Substantially — a cosmetic defect and a data-corruption defect are not the same event. This uses one typical figure, so run it separately per severity band if the mix is uneven.

Only where failure is catastrophic. For most software the cost of the last few defects exceeds their impact, and pursuing zero displaces work that would deliver more value.