QA metrics calculator: DRE, leakage, pass rate and defect density

What this tool does

Six inputs, five outputs. You enter defects found during testing, defects found in production, tests executed, tests passed, and optionally a size figure with a unit (KLOC, function points, modules or story points). It calculates defect removal efficiency, defect leakage, pass rate, the failed count, and defect density. Anything you leave blank is skipped, and each result is colour-graded with a sentence explaining what the number is telling you.

What each metric actually means

Defect Removal Efficiency is the share of all known defects your process caught before users did. 85 internal and 7 escaped gives 92.4 percent. At 90 or above, your process catches the large majority before release — this is the number worth quoting in an interview. Between 75 and 90, roughly one defect in four or five reaches production, and the useful question is which layer is missing them. Below 75, the usual cause is thin coverage at the API and integration layers, not a shortage of UI tests.

Defect Leakage is DRE's mirror — the share your users found instead of your tests. Ten percent or less is healthy. The single value matters far less than the trend across releases.

Pass Rate is the least trustworthy metric here, in both directions. Below 85 percent, separate genuine failures from flaky ones before you report it; a flaky suite makes the number meaningless. Above 95 percent, suspect the opposite problem — a suite that always passes may have weak assertions or tests that cannot fail.

Defect Density is defects per unit of size. Its real use is comparative: run it per module and the outlier tells you where to focus next. Comparing your density against an industry figure is close to useless, because size units are not standardised across teams.

On coverage

Coverage is the metric interviewers ask about most and the one most often misused. Line coverage tells you which code was executed, not which behaviour was verified — a test with no assertions still produces coverage. Requirements coverage (which acceptance criteria have at least one test) is more honest, and neither belongs in a report without escaped-defect data next to it. Coverage plus DRE says something. Coverage alone says only that code ran.

Common mistakes

Quoting a number you cannot interpret. In an interview this is worse than not quoting one. Every result here comes with an interpretation for that reason.

Reporting a single metric alone. DRE without a flake rate, or coverage without escaped-defect data, is a vanity number. What earns senior marks is naming which metrics you track together and what decision each one would change.

Counting only what is convenient. If production defects are logged in a different system and quietly excluded, DRE inflates. Agree the counting rule before the number goes in a deck.

Use one release or one sprint per calculation. Mixing periods produces a number that describes nothing. All calculation runs in your browser; nothing you enter is sent anywhere.