Defects keep leaking into production. How do you fix it?

What the interviewer is really testing

• Root-cause thinking. Do you treat the symptom, or do you find out why defects are escaping?
• Data, not opinions. Can you measure quality, and show whether it's getting better or worse?
• Ownership, not blame. Do you fix the process, or point fingers at testers or developers?

The weak answer vs the strong answer

Here's the answer most candidates give: "We'll write more test cases and test harder."

It sounds responsible, but here's what the interviewer hears. You're treating the symptom, not the cause. You haven't looked at which defects escaped, or why. And you've quietly accepted that it's QA's fault, when the real cause might be in the requirements, in late code changes, or in the test environment.

More testing can be part of the solution. But without knowing the cause, you're just testing harder in the wrong places.

The 5-step answer

1. Measure the leakage. Defect leakage is the number of defects found in production, divided by the total defects found, times one hundred. Track it for every release. Without this number, you're only arguing about opinions.
2. Classify every escaped defect. For each defect that reached production, ask one question: why did we miss it? Was it a requirement gap, a test we never wrote, a difference in the environment or test data, a regression gap, or a late change that skipped testing? Within a few releases, you'll see the patterns.
3. Fix the process for each cause. Requirement gaps need reviews with the business analyst, developer and tester together, plus traceability from each requirement to its tests. Regression gaps need automation. Environment problems need production-like test data. And late changes need a proper code freeze.
4. Shift left. Bring QA into story refinement, agree the acceptance criteria before development starts, and encourage developers to add unit and API tests early. A defect caught in a requirement review costs a fraction of one found in production.
5. Track the trend and share it. Put leakage per release on one simple dashboard, review it with the whole team, not just QA, and celebrate when it goes down.

A real example

Let me give you a real example from my own experience. I'll keep the client anonymous.

I was working on a program for a US healthcare payer, with frequent releases. After almost every release, issues were showing up in production, and QA was getting the blame.

So instead of just adding more test cases, we did a root-cause analysis of every defect that escaped. Three patterns came out, and none of them was simply bad testing.

The first was requirement gaps: unclear or changing requirements, with edge cases nobody had written down. We started reviews with the business analyst, developer and tester together, wrote clear acceptance criteria, and kept a traceability matrix from each requirement to its tests.

The second was late changes. Fixes were going in at the last minute, without full testing. We brought in a proper code freeze. After the freeze, only approved fixes went in, each with an impact analysis and targeted regression testing.

The third was environment and test data. Our test environment and data didn't behave like production. So we built production-like test data, masked to protect member information, and checked the environment before every UAT cycle.

The result: far fewer production incidents.

Far fewer defects escaped, and we needed far fewer emergency hotfixes.

We tracked leakage for every release, so the improvement was visible to everyone.

And quality became a team metric, not just a QA problem.