Free tool · Performance and metrics

Defect density and leakage calculator

Enter a release’s defect and test counts and get every standard defect metric with its formula and the numbers behind it. Choose how your organisation defines leakage, compare against the previous release, and export a release quality summary.

Defect metrics calculatorFree

LiveLocal only

Enter one release’s defect and test counts to get defect density, leakage, DRE and the other release metrics, each with its formula.

Examples

Compare with a previous release

The fields below edit the current release. Size unit, window and options apply to both.

Name of the current release

Defects

Count pre-release defects by phase

Reviews and static analysis

Unit and integration testing

System testing

User acceptance testing

Defects found after release

Within (days)

Valid defects only: leave out rejected reports. Use the same post-release window every release, such as 30 days.

Split by severity

Critical

High

Medium

Low

Size

Size unit

Size of the release (KLOC)

KLOC is thousands of lines of code changed or delivered. Whatever the unit, measure it the same way every release.

Test execution

Tests planned

Tests executed

Passed

Failed

Blocked (not run)

Defect handling

Reports rejected

Defects fixed

Reopened

Rejected means closed as not a defect, duplicate or cannot reproduce. Reopened means a fix failed retest.

Defect leakage definition

Defects after release divided by defects found before it. Can exceed 100%. Organisations define leakage differently, so use the one your reports already use.

Release quality summary: v3.8

62 of 67 known defects were found before release (DRE 92.5%). 5 reached production in the first 30 days after release.

Defect density
3.72 per KLOC
v3.7: 4.25 per KLOC · -0.53, better
(defects before release + defects after release) ÷ size in KLOC
(62 + 5) ÷ 18 = 3.72 per KLOC
Compare it only with releases measured the same way: the same size unit, the same severity filter and the same post-release window.
Defect removal efficiency (DRE)
92.5%
v3.7: 86.8% · +5.8 pts, better
defects before release ÷ (defects before release + defects after release) × 100
62 ÷ (62 + 5) × 100 = 92.5%
The share of all known defects removed before users saw them. It rises over time only if production defects stop arriving, so quote it with the window used.
Defect leakage (against pre-release defects)
8.1%
v3.7: 15.3% · -7.2 pts, better
defects after release ÷ defects before release × 100
5 ÷ 62 × 100 = 8.1%
This version can exceed 100% when production finds more than testing did. State the definition whenever you report it.
Defect escape rate
7.5%
v3.7: 13.2% · -5.8 pts, better
defects after release ÷ (defects before release + defects after release) × 100
5 ÷ (62 + 5) × 100 = 7.5%
The share of all known defects that reached production. It is the complement of DRE: the two always add up to 100%.
Defect rejection ratio
12.7%
v3.7: 16.9% · -4.2 pts, better
rejected reports ÷ (valid defects before release + rejected reports) × 100
9 ÷ (62 + 9) × 100 = 12.7%
High values usually point to unclear requirements or environments rather than careless testers. Count duplicates and "cannot reproduce" the same way every release.
Reopen rate
6.9%
v3.7: 12.7% · -5.8 pts, better
reopened defects ÷ defects marked fixed × 100
4 ÷ 58 × 100 = 6.9%
Fixes that failed retest. A rising rate often means fixes are rushed or retests happen in a different environment from the fix.
Test execution rate
95.7%
v3.7: 96.3% · -0.5 pts, worse
tests executed ÷ tests planned × 100
402 ÷ 420 × 100 = 95.7%
How much of the planned testing actually ran. Blocked tests are not executed, so they lower this rate.
Test pass rate
93.8%
v3.7: 91.4% · +2.4 pts, better
tests passed ÷ tests executed × 100
377 ÷ 402 × 100 = 93.8%
Read it alongside the execution rate: a high pass rate over a small share of the plan says little about the release.

Detection by phase

Defects found in each phase, the defects still present when it started, and the share it caught
Phase	Found	Still present	Caught
Reviews and static analysis	12	67	17.9%
Unit and integration testing	26	55	47.3%
System testing	18	29	62.1%
User acceptance testing	6	11	54.5%

Still present counts the defects found in this phase, every later phase and production. Caught is the ISTQB defect detection percentage for the phase.

By severity

Defects before and after release, DRE and escape rate for each severity
Severity	Before	After	DRE	Escape rate
Critical	2	0	100.0%	0.0%
High	14	1	93.3%	6.7%
Medium	30	3	90.9%	9.1%
Low	16	1	94.1%	5.9%

Export

A release quality summary for Confluence, a wiki, a pull request or a release note.

ReadyRuns in your browser. Nothing you enter is uploaded.Exports: Density, leakage, DRE, report

How to use

How to use the Defect metrics calculator

1Pick an example to see the metrics on realistic numbers, or enter your own: defects found before release, by phase if you track it, and defects found in production within a fixed window.
2Add the size of the release in KLOC, function points or your own unit, then the test counts and the rejected, fixed and reopened defects. Leave a field blank if you do not track it.
3Choose the leakage definition your reports already use, and tick Compare to enter the previous release alongside this one.
4Read each metric with its formula and note, fix anything flagged under Check the inputs, then export the summary as Markdown for a release report or as CSV.

Guide

What testers should know

The formulas

Every metric here is a ratio of two counts, so its value depends entirely on what is counted. Each formula below uses valid defects only: reports closed as not a defect, duplicate or cannot reproduce are left out and tracked separately as the rejection ratio.

Defect density
defects ÷ size
The ISTQB glossary defines it as the number of defects per unit size of a work product. Size is usually thousands of lines of code (KLOC) or function points. This calculator counts defects found before and after release together.
Defect removal efficiency (DRE)
defects before release ÷ (defects before release + defects after release) × 100
The share of all known defects removed before users met them. ISTQB calls the same calculation for a single test level the defect detection percentage.
Defect leakage
defects after release ÷ defects before release × 100 or defects after release ÷ all defects × 100
Two definitions are in common use, explained in the next section. The second is identical to the escape rate.
Defect escape rate
defects after release ÷ (defects before release + defects after release) × 100
The share of all known defects that reached production. It always equals 100% minus DRE.
Defect rejection ratio
rejected reports ÷ (valid defects before release + rejected reports) × 100
How many reports raised during testing turned out not to be defects.
Reopen rate
reopened defects ÷ defects marked fixed × 100
How many fixes failed retest. Count a defect once even if it was reopened more than once, or report the repeats separately.
Test execution rate and pass rate
executed ÷ planned × 100 passed ÷ executed × 100
Blocked tests have not run, so they lower the execution rate and do not appear in the pass rate.

Why the definition of defect leakage varies

There is no single standard formula for defect leakage, and the two common ones give different numbers from the same data. Some organisations divide the defects found after release by the defects found before it. Others divide by all defects, before and after, which makes leakage the same as the escape rate.

With 48 defects found before release and 12 after, the first definition gives 25% and the second gives 20%. The first can exceed 100% when production finds more than testing did; the second cannot. Neither is wrong, but a leakage figure means nothing without its definition, and two teams comparing leakage must first agree on one. Some teams also use leakage between test phases, such as defects found in UAT that system testing should have caught; the phase table here covers that.

Phase containment and detection percentage

Counting defects by phase shows where they are caught. For each phase, the calculator divides the defects it found by the defects still present when it started: those found in that phase, in every later phase and in production. This is the defect detection percentage, which the ISTQB glossary defines as the number of defects found by a test level divided by the number found by that test level and any other means afterwards.

Strict phase containment needs one more field: the phase in which each defect was introduced. A requirements defect found in system testing escaped two phases, and only a team that records the origin of each defect can measure that. If your tracker records it, calculate containment per origin phase; if not, the detection percentage is the closest measure available from counts alone.

How to count consistently

A metric compared across releases is only as good as the counting behind it. Decide these rules once, write them in the test plan, and apply them to every release.

Valid defects only
Exclude rejected, duplicate and cannot-reproduce reports from every defect count, and report them through the rejection ratio instead.
A fixed post-release window
Count production defects for the same number of days after each release. The longer the window, the more defects arrive and the lower DRE falls, so a release measured at 14 days cannot be compared with one measured at 90.
One severity scale
Use the same severity definitions in testing and production, and decide whether low-severity defects count. Many teams report leakage for critical and high severity separately, because one escaped critical defect matters more than ten cosmetic ones.
The same size measure
Measure KLOC the same way each time: changed or delivered code, with or without tests and generated files. Story points are relative to one team, so they compare that team with itself and nothing else.
Where a defect is counted
Decide whether a defect found in staging by the release team counts as before release, and whether defects in third-party components count. Write the answer down.

Using defect metrics without gaming them

Once a metric becomes a target, people change their behaviour to move the number. Severity is quietly downgraded so that leakage of critical defects looks lower. Defects found in reviews go unrecorded because they lower DRE for the review phase. Production defects are logged as change requests. Code grows and defect density falls without the product getting any better.

Read the metrics together rather than one at a time: a high pass rate means little next to a low execution rate, and a falling rejection ratio is good only if defects are still being reported. Watch trends across several releases rather than a single value, and use the numbers to ask where defects are being missed, not to rank testers or teams.

Use it alongside

QAble service

QA audit

A QAble QA audit reviews how your team finds, records and fixes defects, measures where they escape to production, and sets out the changes that will catch them earlier.

Explore the service

FAQ

Frequently asked questions

What is a good defect density?

There is no universal figure. Defect density depends on the size unit, the language, how thoroughly defects are recorded, and whether low-severity defects count, so a number from another organisation is rarely comparable. Use your own previous releases, counted the same way, as the baseline.

What is the difference between defect leakage and defect escape rate?

The escape rate is always defects after release divided by all defects. Defect leakage is defined two ways: some organisations use that same formula, and others divide defects after release by defects found before it, which gives a higher number. The calculator lets you choose and labels which one it used.

How do you calculate defect removal efficiency?

Divide the defects found before release by the total found before and after release, and multiply by 100. With 48 found in testing and 12 in the first 30 days of production, DRE is 48 ÷ 60 × 100 = 80%. Always state the post-release window with the figure.

Should rejected or duplicate defects be counted?

Not in defect density, DRE or leakage, because they are not defects in the product. Track them separately with the defect rejection ratio, which shows whether reports are clear and whether test environments match production.

Can I calculate defect density with story points instead of KLOC?

Yes, choose Other and name the unit. The result is defects per story point, which is useful for following one team over time. Story points are estimated differently by every team, so the figure should not be compared across teams.