The cost escalation model
A defect costs more the later it is found because more work has been built on top of it and more people have to be involved in fixing it. A requirement defect found in a review costs a conversation and an edit. The same defect found in design costs a rework of the design: call it 5 times as much. Found in coding, 10 times. Found in system test, 20 times: a defect report, a triage, a fix, a rebuild, a retest. Found in acceptance, 50 times, because the customer is now involved. Found in production, 100 times: an incident, a hotfix release, support tickets, possibly a refund or a regulatory notice. The exact multipliers vary by study and by organization, but the shape is consistent: an order of magnitude between early and late, and another between late and live.
The model makes two things measurable: the value of finding defects earlier within the test process, and the value of finding them before release at all. The second is the ROI of testing argument; the first is the argument for reviews and inspection.
A worked ROI model for six testers
| Line | Value | How it is derived |
|---|---|---|
| Testers | 6 at 95,000 fully loaded | Salary, benefits, management overhead, workspace |
| Staff cost | 570,000 | 6 times 95,000 |
| Environments, tools, licenses | 130,000 | Test environments, device pool, tool categories in use |
| Total annual testing cost | 700,000 | Staff plus environment and tools |
| Defects found before release | 1,150 | From the defect tracker, all severities, one year |
| Share that would otherwise reach production | 35 percent, about 400 | Estimated from historical leakage before the team existed or from a comparable product |
| Cost per defect fixed in test | 600 | Report, triage, fix, rebuild, retest: about 8 hours of mixed effort |
| Cost per defect fixed in production | 4,800 | Incident, hotfix release, support, communication: about 8 times the test cost |
| Avoided fix cost | 1,680,000 | 400 times (4,800 minus 600) |
| Severe escapes avoided | 20 at 25,000 | 5 percent of the 400 would have caused an outage or a customer loss |
| Avoided severe cost | 500,000 | 20 times 25,000 |
| Total avoided cost | 2,180,000 | 1,680,000 plus 500,000 |
| ROI | About 210 percent | (2,180,000 minus 700,000) divided by 700,000 |
The share that would escape is the honest heart of the model. Not every defect the team finds would have reached a customer. Developers would catch some, the customer acceptance step would catch others, and some are trivial enough that nobody would notice. Thirty-five percent is a reasonable figure for a product with modest unit testing and no formal acceptance stage; a product with strong developer testing might justify 20 percent, and a product with none might justify 50. Get the figure from your own leakage history if you have one, and say so on the slide.
Presenting it to a sponsor on one slide
A sponsor does not want the table. Put three numbers on one slide: what testing costs (700,000), what it saved (2.2 million in avoided defect cost, of which 500,000 is avoided outages), and the ratio (every unit spent on testing returned about three). Under the numbers, one line of method: based on 1,150 defects found, 35 percent of which would have reached customers, at historical fix and incident costs. Under that, one line of ask: the decision you want, whether that is holding the budget, adding two testers, or funding an environment. The table goes in the appendix for the finance reviewer, who will look at exactly one number, the 35 percent, and ask where it came from.
The escape share drives everything. Take it from your own defect leakage data if you have any; if not, state the assumption on the slide and offer to measure it over the next two releases. Sponsors trust a stated assumption far more than a hidden one.
The limits of the ROI argument
The model counts detection, which is the appraisal cost in the cost of quality framework: money spent finding defects. It does not count prevention, which is money spent so that defects are not made in the first place: reviews, clear requirements, developer testing, pair work. Prevention usually has the higher return, because it removes the defect at the 1x stage rather than finding it at the 20x stage, and a mature organization shifts spend from appraisal to prevention over time. If the ROI argument is used to grow a test team without any prevention effort, the organization is optimizing the wrong thing.
Second, avoided cost is not cash. The 2.2 million does not appear in an account; it is an estimate of what would otherwise have been spent. Finance reviewers know this and will discount it. Present it as cost avoidance, never as savings. Third, the model ignores the benefits that do not fit it: faster releases because the regression suite gives confidence, fewer late-night incidents, the information testers provide that changes what gets built. Those are real but hard to price, so mention them and leave them out of the arithmetic. The defect leakage and cost metrics that feed this model are worth collecting even if you never make the ROI argument, because they tell you where in the process your defects are being made.
Making the model yours
Replace the multipliers with your own within two releases. Log, for every production defect, the hours spent on incident response, fix, release and support, and the customer-facing cost where there was one. Log, for a sample of test-phase defects, the hours from report to closed retest. Two releases of that data give you a fix-cost ratio that belongs to your organization, and a leakage percentage that replaces the 35 percent assumption. Then the ROI slide stops being a model and becomes a report. It also becomes the evidence base for a test process improvement program, because the same data shows which stage is producing the defects.
Common questions
How do you calculate the ROI of testing?
ROI equals avoided cost minus testing cost, divided by testing cost. Avoided cost is the number of defects found that would otherwise have reached production, multiplied by the difference between the production fix cost and the test fix cost, plus the cost of any severe incidents avoided.
What is the cost of a late requirement defect?
In the common escalation model a requirement defect found in production costs about 100 times what it would have cost to fix during requirements review. The exact multiplier varies; the order of magnitude does not.
Is the 1x to 100x model accurate?
It is an order-of-magnitude model drawn from several older industry studies, not a law. Use it to structure the argument, then replace the multipliers with figures from your own incident and defect records.
What is cost of quality?
A framework that splits quality spending into prevention (avoiding defects), appraisal (finding defects, which includes testing), internal failure (fixing defects before release) and external failure (fixing them after). The ROI of testing model compares appraisal spend against avoided external failure.
Why do finance teams discount testing ROI?
Because avoided cost is not cash and the escape percentage is an estimate. State the assumption, source it from leakage data where possible, and present the result as cost avoidance rather than savings.
Should the ROI argument be used to grow the test team?
Only alongside a prevention argument. Detection has a positive return, but prevention through reviews and developer testing has a higher one. A team that only adds testers is treating the symptom.
Sources
- NIST Planning Report 02-3, The Economic Impacts of Inadequate Infrastructure for Software Testing (2002)
- Barry Boehm and Victor Basili, Software Defect Reduction Top 10 List, IEEE Computer (2001)
- ISO/IEC 25010:2023, SQuaRE product quality model
Further reading named in the text
- Barry Boehm, Software Engineering Economics (Prentice Hall, 1981)
- Capers Jones and Olivier Bonsignour, The Economics of Software Quality (Addison-Wesley, 2011)
- Rex Black, Managing the Testing Process, 3rd edition (Wiley, 2009)
- Philip Crosby, Quality Is Free: The Art of Making Quality Certain (McGraw-Hill, 1979)
- Stephen Kan, Metrics and Models in Software Quality Engineering, 2nd edition (Addison-Wesley, 2002)
This guide is part of the test management hub. It is best read alongside TMMi and test estimation, which cover the neighbouring questions.