Escaped Bugs and Problems - the full spectrum of what reaches production

Series: QA Leadership · Article 3 of 9

It was a Friday evening. The team's DDR was 91%. Regression passed beautifully. Confidence Score: 89% - GO. The release shipped. And forty minutes later the alerts started rolling in.

The next day at the retrospective, one question came up: “How is this possible - DDR 91%, and the client couldn’t pay for half an hour?”

The answer is both simple and painful: because DDR measured only bugs in the code. And the problem was in the infrastructure configuration. And that is exactly the gap this article is about.

The client doesn't distinguish whether the service went down because of a code bug, a bad SSL certificate, or a wrong feature flag. To them - and to your business - it's all the same thing: production is down.

Escaped Problem - a broader definition

In the previous article we talked about DDR - the metric for defect detection effectiveness. DDR asks: how many bugs do we catch before they reach production? But that definition assumes the only problems are bugs in the application code.

Reality is different. An Escaped Problem is any problem discovered by a customer or by monitoring after deployment - regardless of its source. Four categories, four entirely different ways of arising, four different ways of preventing them.

Four types - one shared consequence

Before you start measuring, you need to know what you’re measuring. Here is the full taxonomy of escaped problems with the typical percentage share in the organizations I’ve worked with.

The sum doesn’t add up to 100% - because a few percent are mixed situations, hard to classify cleanly. The proportions will differ in your organization - but the taxonomy itself is almost universal.

Code vs infra vs integration - the key differences

Each type of escaped problem has a different source, a different warning signal and a different prevention method. The table below is your navigation map.

How to collect and categorize - a practical guide

Most teams collect only bugs from Jira. That’s like measuring the temperature in one room and claiming you know the climate of the whole building. Here’s what to add and how to connect it.

Data sources

The categorization process - step by step

Implementation checklist

Check which data sources you already have connected in your team.

Data that says more than a single counter

Instead of one number “escaped bugs = 12” - two charts that give a completely different level of insight into what’s really going on.

How to present this to the business

The number of escaped problems alone stops being enough once you have the type distribution and the cost of each. Here’s how to turn that data into a narrative.

Instead of: *"we had 8 escaped bugs."* Say: *"we had 8 escaped problems - 5 code defects, 2 configuration problems and 1 integration failure. Total cost: about 68 hours. Infra and integrations need a separate strategy."*

What the full taxonomy changes

The client doesn't report a problem labeled "type: infrastructure". To them - and to your business - one thing matters: does it work. Measure everything that can stop working.

In the next article

Article four covers Issues per Release - a code-maturity metric that reshapes the conversation with the Engineering Manager. It doesn’t ask how many bugs you found - it asks how clean the code you received for testing was.

Spoiler: this is the metric that often reveals the problem lies not with QA but with the development process - and it gives you the data to have that conversation from a position of facts, not opinions.