How is defect removal efficiency calculated, and what does a low value for one phase tell you?

## What it measures Defect removal efficiency — also described as containment or filter effectiveness — asks how good one stage of work is at catching the defects that were already present when that stage ran. phase efficiency = found in the phase / (found in the phase + escaped the phase) x 100 "Escaped" means found later, in a subsequent phase or after release, but present at the time the phase ran. The release-level figure compares everything found before release against everything found before release plus everything reported after it, inside a fixed observation window. ## Why the injection point matters A defect introduced during integration was not available for an earlier code review to catch, so it is not an escape from that review. A correct per-phase figure therefore needs each defect's injection point, which is a classification judgement made at triage or during a post-fix analysis. Teams that skip that step and treat every later-found defect as an escape from every earlier stage systematically understate every early filter, and then draw the wrong conclusion about which filter to invest in. ## A worked example A subscription renewal job release records: requirement and design review 23, code review 41, component testing 58, integration testing 34, system testing 26, and 9 defects reported from the field in the first 90 days. Total known defects: 191, of which 182 were found before release. release efficiency = 182 / 191 = 95.3% system testing = 26 / (26 + 9) = 74.3% integration testing = 34 / (34 + 26 + 9) = 49.3% code review = 41 / (41 + 58 + 34 + 26 + 9) = 24.4% Read down the table: system testing is the strongest filter in this process; the code review lets roughly three quarters of what it could have seen through to later, more expensive stages. Whether that is worth fixing is a cost argument. The claim that a defect costs dramatically more to remove the later it is found is widely repeated and directionally uncontroversial; the specific multipliers often quoted (ten times per phase, a hundred times in the field) trace back to a small number of old studies and are genuinely contested. Argue the direction, not a number. The 9 escapes here include a currency-rounding drift that only appeared at a 1,200-request-per-minute peak — fractional cents accumulating across concurrently prorated renewals. No component-level filter was ever going to catch a defect whose trigger is load. That is the second way to read the table: a low figure sometimes means the filter is weak, and sometimes means that class of defect is invisible at that level. Deciding which one you are looking at requires reading the escaped defects, not just counting them. ## Provisional by construction The escape count is unknown at release. Any figure computed on release day is an upper bound that only ever falls as the field reports arrive. So: fix an observation window — 30, 90 or 180 days — state it alongside the figure, and expect a revision. Comparing one release's 30-day figure with another's 180-day figure is a bookkeeping error dressed as a trend. ## Where it is useful and where it is not Useful: comparing filters against each other inside one process; tracking a single filter's trend across releases under a stable definition; building the investment case for an earlier filter, because the measure names which stage is leaking rather than just asserting that quality is poor. Not useful: as an absolute benchmark between organisations, since defect definitions, phase boundaries and observation windows all differ; as an individual or team target, because the numerator is made of human filing decisions and moves the moment it is rewarded; and on tiny denominators, where a phase that found 3 and leaked 1 reports 75% with an enormous error bar around it. Finally, note what the measure cannot see at all: defects that nobody has found in either bucket. It scores the filters against each other, not against reality.