Defect Detection Ratio - how to measure effectiveness before anything reaches production

Series: QA Leadership · Article 2 of 9

You walk into a 1:1 with your Engineering Manager. One question lands: "How many of those bugs do you catch before they reach the customer?" - and the conversation starts to fall apart. Not because you test badly. Because you don't have one single number.

And the conversation falls apart. Not because you test badly. Because you don’t have a number that answers that question directly. One. Concrete. Ready.

That number exists. It’s called Defect Detection Ratio - and it’s the topic of this article.

What DDR is - and what it isn’t

Defect Detection Ratio is the share of defects caught by QA before reaching production, against all defects found in total - both before and after release. In other words: out of all the problems that ultimately surfaced - how many did you catch yourselves, before the customer saw them?

This is a metric of testing process effectiveness. Not activity. It answers the question: how well do we work as a filter before production?

DDR asks something fundamentally different from pass rate or coverage: does your testing process actually catch what matters?

DDR is not the same as pass rate. You can have a 99% pass rate and a 50% DDR - if your tests don’t cover the areas where the bugs live.

DDR is not the same as coverage. You can hit 90% of the code and not check a single critical business scenario. Touching is not the same as verifying.

From simple to advanced formula

Basic version

Weighted version

The basic formula treats every bug equally. But a payments-blocking bug weighs more than a typo in a tooltip. It’s worth extending the formula with weights.

DDR calculator

Enter your numbers and check the result. Toggle weighted mode to factor in bug criticality.

How to read the score - thresholds and context

DDR is not absolute truth. It’s an indicator - and like every indicator, it requires interpretation. But certain industry thresholds are worth knowing as a reference point.

Industry context matters. In financial and medical systems 90%+ is a minimum, not an aspiration. In a fast-iterating startup, 80% at high release frequency may be a conscious, acceptable tradeoff.

Why you can’t start today - historical data

One of the most common mistakes when rolling out DDR: the team starts measuring from the current sprint and after a month has one data point. One. From which no conclusion can be drawn.

DDR without history is like a map without a scale. You know you're somewhere - but you don't know which direction you're heading and how fast.

Before you start measuring “from now”, do something much more valuable: reconstruct data backwards. Most organizations have all the data they need - nobody has just connected it in this specific way yet.

Where to find historical data

project = MYAPP AND issuetype = Bug AND created >= "2025-01-01"
ORDER BY created ASC

Seasonality and patterns

With 12 months of data, you start seeing patterns your intuition won’t catch.

Minimum viable approach - how to collect the data practically

Case study - from 74% to 94% in four quarters

A seven-person team (5 devs, QA, automation engineer), SaaS platform for enterprise customers. At the start of the year DDR 74% - three in ten bugs reach production.

"Every 5 percentage points of DDR is on average 4 fewer escaped bugs per quarter, at 8 hours each - that's 32 senior hours. Per quarter." - Budget approved.

When DDR lies - three traps

Every metric has weaknesses. DDR has three specific ones - and it’s worth knowing them before you start trusting it blindly.

DDR in business hands - the most dangerous trap

You won’t find this trap in the ISTQB syllabus. And it’s the most dangerous, because it touches not the measurement method but how it’s interpreted by people who don’t know the context.

Picture this: you show your Product Owner DDR 94%. They’re happy. They say: “great, we’re safe, we’re shipping.” But they don’t know that in the same quarter the number of releases went from 3 to 10.

DDR rises across all four quarters. Looks great. But the absolute count of escaped bugs grew through Q1-Q3. For three quarters the customer experienced more problems in production - despite rising DDR.

DDR never works alone. It only fully makes sense alongside Escaped per Release (article 5) and Number of Releases (article 6). When presenting DDR to stakeholders - always show it with at least one context metric.

How to roll out DDR in four steps

Enough theory. Here’s what to do in the coming week.

DDR in conversation with the business

Three contexts. Three levels of detail. One indicator at the base of every conversation.

What DDR tells you - and what it doesn’t

Use DDR as one of the five letters of the alphabet. Together they form a word. Alone - they're just letters.

In the next article

The third article in the series covers Escaped Bugs & Problems - and it starts with a question most QA teams ask too rarely: are we really measuring everything that escapes to production?

Spoiler: almost never. And what we leave out is often more important than what we count.

Series links