In 30 seconds
- Defects divided by size, such as per thousand lines of code.
- Highlights components with quality problems.
- Use for trends within a team, not for ranking people.
How it's calculated
Defect density = defects found / size. Size is often measured in thousands of lines of code, function points, or stories delivered.
Using it well
- Compare components within the same product to find hotspots
- Track trends release over release
- Focus refactoring and testing on the densest areas
Traps
- Lines of code vary by language and style
- More testing finds more defects, which can look worse
- Ranking teams invites under-reporting
Pair with escaped defects for a fuller picture.
Myth vs reality
Myth · Low density means high quality.
Reality · It might mean little testing.
Myth · It's useful for comparing teams.
Reality · Context differences make that misleading.
Myth · All defects are equal.
Reality · Weight by severity for a truer picture.
FAQ
What size measure is best?
Whatever you can measure consistently for your codebase.
Should we include minor defects?
Track severity separately.
How often should we measure?
Per release or quarterly.