Defect removal efficiency
Defect removal efficiency is the proportion of a release's defects that the team found and removed before shipping, compared with the total found before and after, once production has had time to reveal the escapes. A ratio close to one means the test process caught nearly everything; a low ratio means users are finding what testing missed.
The longer version
The calculation takes two counts for one release. The first is defects found during development and testing, before the release date. The second is escaped defects found in production over a fixed window after release, long enough for users to exercise the code, commonly a release cycle or a quarter. Efficiency is the first count divided by the sum of both. If a team found ninety defects before release and users found ten after, it removed nine defects in every ten before shipping. The figure is retrospective by construction: it cannot be known on release day, only once the window closes.
The measure is often confused with defect density, which is the count of defects per unit of code size and says how buggy the code was rather than how well testing filtered it. The two move independently. A team can ship dense, defect-ridden code with high removal efficiency, because it found almost all of it, and clean code with low efficiency, because the few defects it had all reached users. Efficiency is a property of the test process; density is a property of the code and the people writing it.
The number is only as honest as the two counts. If pre-release defects are logged casually, or developers fix things they notice without filing them, the numerator shrinks and efficiency looks worse than it is. If production bugs are reclassified as configuration issues or user error, the denominator shrinks and efficiency looks better. The window matters too: close it early and escapes go uncounted. A team gets a usable figure by tagging every defect with where it was found at intake and by agreeing, in advance, on how long production gets to reveal escapes. Reading the trend across releases is more useful than any single value.
Common questions
How is defect removal efficiency calculated?
Divide the defects found before release by the total of those found before and those found in production afterwards, for the same release, once the agreed post-release window has closed. A team that found forty-five before and five after removed nine in ten before shipping. The result is reported as a ratio or a percentage.
What is a good defect removal efficiency?
There is no figure that fits every team, because the count depends on how carefully pre-release defects are logged and how long production is watched. A team gains more from its own trend across releases than from any published benchmark: a falling ratio means escapes are rising relative to what testing catches, whatever the absolute value.
What is the difference between defect removal efficiency and defect density?
Density counts defects per unit of code size and describes how buggy the code was. Removal efficiency compares defects caught before release with those found after and describes how well the test process filtered them. Dense code can be filtered well and clean code badly; the two measures answer different questions.
When should defect removal efficiency be calculated?
Once the post-release window the team agreed on in advance has closed, and per release rather than per month, because the count of escapes needs production to have exercised the code. Calculated on release day it reads as perfect, since no escape has been found yet. Teams usually compute it at the retrospective of the following cycle and read the trend across several releases.
How can a team improve its defect removal efficiency?
By tracing each escape to the test stage that should have caught it and adding the case, the data or the environment that was missing, so the next release filters that class of defect before it ships. Logging pre-release defects properly matters as much, because fixes made without a record shrink the numerator. Broader coverage of invalid inputs and error paths usually raises the ratio faster than more happy-path tests.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.