Defect Density: Formula, Examples, and Benchmarks
Defect density is the number of confirmed defects divided by the size of the software they were found in. It is one of the oldest QA metrics — and one of the most misused.
The formula
Defect density = defect count / sizeSize is usually measured in KLOC (thousands of lines of code). Agile teams often substitute story points so the metric survives refactors that change line counts.
Worked example
Your team ships a release: 24 confirmed defects were found in a component of 18,000 lines of code.
24 defects / 18 KLOC = 1.33 defects per KLOCAgainst the common industry heuristic of ~1 defect per KLOC as an acceptable upper bound, 1.33 suggests this component needs attention — more review coverage, more targeted tests, or a closer look at its churn history.
Try your own numbers in the free Defect Density Calculator.
What counts as “good”?
Published industry figures vary widely by domain, but as rough bands:
| Density (defects/KLOC) | Interpretation |
|---|---|
| ≤ 0.5 | Excellent — typical of mature, well-tested code |
| 0.5 – 1.0 | Good — within the common benchmark |
| > 1.0 | Needs attention |
Safety-critical software targets far lower numbers; early-stage products often run higher. Compare a component against its own history, not against other companies.
Where the metric misleads
- Counting found defects, not existing ones. A low density can mean good code — or weak testing. Read it alongside test coverage and escape rate.
- Gaming by size. Verbose code lowers density without improving quality.
- Severity blindness. Ten cosmetic bugs and ten data-loss bugs produce the same number. Weight by severity when using density for release decisions.
Used carefully — trended over time, per component, alongside severity — defect density is a cheap early-warning signal for where quality effort should go next.