How much of defects does a single test stage catch?

Capers Jones's data shows most individual forms of testing remove below 35% of the defects present, roughly one bug in three. In his worst-case removal table the individual stages run: unit test 28%, function test 31%, regression test 10%, component test 28%, performance test 6%, system test 32%, acceptance test 13%. No single test stage is a safety net on its own, which is why effective teams layer many removal activities.

Testing and Defect-Removal Effort: What Share of Software Cost?

Q: Why is testing so expensive if each stage only catches a third of defects?

Because a third per stage means you need many stages to reach a high cumulative defect removal efficiency, and every stage adds labour. Testing alone, with no upstream defect prevention or pre-test inspection, tops out around 81% cumulative removal in Jones's worst-case scenario. Reaching the 99%-plus removal that high-reliability software needs requires a synergistic combination of defect prevention, pre-test removal such as code review and static analysis, and formal testing. Each added layer is more effort, which is how defect removal grows into the largest single cost.

Q: Is testing effort the same as rework?

No. Rework is the labour spent redoing work that was already done, which Capers Jones puts at 20 to 40% of development effort. Defect-removal effort is broader: it includes the testing and inspection used to find defects in the first place, plus the rework to fix them. Testing that finds no defects still costs effort but produces no rework. The two figures overlap but are not interchangeable.

Updated June 2026. Source: Capers Jones, defect-removal efficiency data.

The direct answer

Capers Jones describes finding and fixing bugs as the single largest expense element in the history of software. Across the full development-and-maintenance lifecycle of a large system, roughly 50 cents of every dollar spent goes to finding and fixing defects. Testing effort within a single development project is lower than that headline figure, but defect removal as a whole, which bundles inspection, static analysis, every test stage, and the rework to fix what they surface, is the dominant cost category in most engineering organisations. The reason it grows so large is structural: no single test stage catches more than about a third of the defects present, so reaching high quality means stacking many removal layers, and every layer adds labour.

The 50-cents-on-the-dollar figure

Jones' most-quoted summary of software economics is blunt: the industry spends about 0.50 of every 1.00 expended on development and maintenance finding and fixing bugs. Over a 25-year life expectancy of a large system in the 10,000 function-point range, almost 50 cents of every dollar goes to defect removal. He frames this as the largest single expense element in the history of software, ahead of new feature development.

This is a lifecycle figure, not a development-only one, and it is the reason questions about "testing effort as a percentage of development effort" resist a single clean number. Jones measures the cost of quality as the total cost of removing defects, not as an isolated "testing line item". The testing line item is only the part of defect removal that happens in test phases; the inspection, review, and rework around it belong to the same economic category.

Why no single test stage is enough

The mechanism behind the cost is defect removal efficiency (DRE): the share of the defects present that a given activity finds. Jones' data shows that most individual forms of testing remove below 35% of the defects present, roughly one bug in three. The worst-case per-stage figures from his removal tables:

Test stage	Defects removed (worst-case DRE)
Unit test	28%
Function test	31%
Component test	28%
System test	32%
Acceptance test	13%
Regression test	10%
Performance test	6%

Figures are the individual-stage removal rates from Capers Jones' worst-case scenario, where no upstream defect prevention or pre-test inspection is applied. Real removal rates are higher when stages are well-resourced, but the shape holds: every single stage leaks a large fraction of defects to the next.

How the layers stack up

Because each stage catches only a fraction, cumulative removal depends entirely on how many independent layers you run. In Jones' worst-case scenario, testing alone, with no defect prevention and no pre-test inspection, reaches roughly 81% cumulative defect removal efficiency. That leaves nearly one defect in five escaping to production, each one far more expensive to fix once it is in the field.

His best-case scenario, combining defect prevention, pre-test removal such as code review and static analysis, and formal testing, reaches around 99.96% cumulative removal. Jones' conclusion is that a synergistic combination of prevention, pre-test removal, and testing can top 99%, whereas testing on its own cannot. Reaching that level is more effort, not less, which is exactly how defect removal grows into the largest single cost in the software lifecycle. The way to make it cheaper is not to test less; it is to move removal earlier, where each defect is cheaper to fix, as the Boehm cost-of-change curve shows.

Testing effort vs rework: not the same number

It is easy to conflate two figures that this site keeps separate. Rework is the labour spent redoing work that was already done, which Jones puts at 20 to 40% of development effort and which the rework cost calculator estimates in dollars. Defect-removal effort is broader: it includes the testing and inspection used to find defects in the first place, plus the rework to fix them. A test run that finds nothing still costs effort but produces no rework. The two overlap heavily but are not interchangeable, and the headline 50-cents-on-the-dollar figure is the defect-removal one, not the rework one. The benchmarks page sets out the rework percentile ranges; the measurement guide shows how to track defect removal efficiency on a real team.

Sources

Jones, C. Software Defect Origins and Removal Methods. (Per-stage defect-removal efficiency and cumulative best/worst-case scenarios.)
Jones, C. Applied Software Measurement. 3rd ed. McGraw-Hill, 2008. (Cost-of-quality and defect-removal economics.)
Jones, C. & Bonsignour, O. The Economics of Software Quality. Addison-Wesley, 2011. (Defect removal as the largest single software cost.)

Frequently asked questions

What percentage of software effort goes to testing and defect removal?▼

Capers Jones frames it as the cost of finding and fixing bugs, the single largest software expense. Across the full development-and-maintenance lifecycle of a large system, roughly 50 cents of every dollar goes to finding and fixing defects. Pure testing within one development project is lower, but defect removal as a whole, which includes inspection, static analysis, every test stage, and the rework to fix what they find, is the dominant cost category.

How much of the defects does a single test stage catch?▼

Most individual forms of testing remove below 35% of the defects present, about one bug in three. In Jones's worst-case table the stages run unit 28%, function 31%, regression 10%, component 28%, performance 6%, system 32%, acceptance 13%. No single stage is a safety net on its own.

Why is testing so expensive if each stage only catches a third?▼

A third per stage means you need many independent stages to reach high cumulative removal, and every stage adds labour. Testing alone tops out near 81% cumulative removal in the worst case. Reaching the 99%-plus that high-reliability software needs requires prevention, pre-test removal, and formal testing combined, which is more effort, not less.

Is testing effort the same as rework?▼

No. Rework is the labour spent redoing work, 20 to 40% of development effort per Capers Jones. Defect-removal effort is broader: it includes the testing and inspection used to find defects, plus the rework to fix them. Testing that finds nothing still costs effort but produces no rework.