Defect detection percentage (DDP)
The fraction of product defects caught in a given phase — a measure of how effective each quality gate is.
// Formula
// About this metric
Defect detection percentage (DDP) measures what fraction of all defects in a product were caught in a specific phase of the development lifecycle — requirements review, design review, unit testing, integration testing, UAT, and so on. It answers the question: "how much of our total defect burden is this phase actually catching?"
DDP is useful for evaluating the return on investment of different quality gates. If your unit testing phase catches 5% of total defects and your UAT phase catches 40%, you may be under-investing in unit test quality relative to late-stage manual testing — a signal to shift left.
The metric only makes sense per phase, not as a global number. The natural expectation (based on shift-left quality principles and cost-of-defect research) is that each phase should catch more defects than the phase that follows it: requirements review > design review > code review > unit test > integration test > system test > UAT.
Because phase definitions vary significantly between organisations, published percentage benchmarks ("unit tests should catch 25% of defects") are hard to apply across teams. The most useful benchmark for DDP is your own historical distribution — track it over time to see if earlier phases are becoming more effective.
// Calculator
🧮 Calculator
// Benchmark
// When this is healthy
Per phase, the earliest phases should catch the most defects — requirements review > design review > code review > unit test > integration test > UAT. If your QA phase catches more than your earlier phases combined, that's a process problem, not a QA success.
// Why no numeric benchmark
DDP only makes sense per phase, and phase definitions vary. Published "phase X should catch Y%" numbers exist but aren't widely agreed on.
// When to use this metric
Use DDP per phase at retrospectives and process reviews to evaluate whether your quality gates are pulling their weight. If later phases consistently catch more defects than earlier phases, it is a signal to invest in shifting quality checks earlier.
DDP requires tracking the phase in which each defect was found, which means your defect tracking system needs a "found-in phase" field and consistent classification by QA engineers.
// Common pitfall
If your QA phase catches more defects than your requirements review, design review, and unit test phases combined, that's not evidence that QA is doing great work — it's a process smell indicating that quality checks earlier in the cycle are ineffective or absent. DDP should make you ask "why are we finding so many defects this late?" not "QA is very thorough."