You’ve been in that meeting. The one where the release is delayed by two weeks, and everyone’s eyes slowly turn to the QA team. The whispers start. ‘If only they tested faster.’ ‘They’re the bottleneck.’ ‘We need more QA engineers.’
I’ve seen it a hundred times. And it’s almost always wrong.
Blaming QA for delivery delays is like blaming the messenger for the bad news. The real problem isn’t the testing—it’s everything that happens before the code ever reaches QA.
Let me show you what I mean. I once sat in a post-mortem where a team spent 45 minutes dissecting a QA engineer’s failure to catch a bug. The bug was a null pointer exception. The code that caused it? Written by a developer who had ignored the team’s coding standards, skipped unit tests, and pushed a PR that breezed through code review in under 10 minutes. Nobody blamed the developer. Nobody blamed the code review process. They blamed the person who found the bug.
That’s the problem in a nutshell.
Research from a recent ACM study on five drivers of delivery delays confirms what many of us have felt: delays are rarely caused by a single team. They’re the result of systemic inefficiencies—unclear requirements, flaky builds, slow environment provisioning, and the toxic culture of ‘throw it over the wall to QA.’
QA is the canary in the coal mine. They’re the first to choke on the fumes of upstream chaos. But instead of fixing the mine, we shoot the canary.
Every time you blame QA, you’re guaranteeing that the next release will be even slower. Because the real issues—the ones that cause delays—stay hidden. Requirements stay vague. Code review stays shallow. Unit tests stay absent. And QA keeps getting blamed for the inevitable fallout.
So what’s the alternative? Diagnose, don’t blame.
Look at the data. Where are the biggest delays? Is it the time between code commit and code review? The time between code review and merge? The time it takes to run a full test suite? The time it takes to deploy a staging environment? In my experience, the answer is almost never ‘the testing phase.’
One team I worked with was convinced QA was the bottleneck. We tracked every hour of the release cycle. Turns out, the average PR sat idle for 18 hours waiting for code review. The actual testing took less than 4. The team had a cultural habit of treating code review as a low-priority chore. They fixed that, and release cycles dropped by 40%.
Notice what didn’t happen? We didn’t hire more QA. We didn’t ask them to test faster. We fixed the upstream process.
If you’re leading a team, here’s a simple test: next time a release is late, ask yourself—if QA had infinite capacity and zero bugs, would this release still be late? If the answer is yes (and it usually is), then QA is not the problem.
The most dangerous words in engineering are: ‘It’s a QA problem.’ Those words let everyone else off the hook. They let developers skip writing tests. They let managers skip clarifying requirements. They let the organization skip investing in automation and infrastructure.
Stop blaming QA. Start looking at the system. The delays are a symptom, not a cause. And the cure is never more fingers pointed at the messenger.
FAQ
Q: But what if QA really did miss a critical bug?
A: QA can't catch every bug if the code is built on shaky foundations. The real issue is that code quality and testing practices upstream are flawed. Blaming QA for missing a bug is like blaming the fire alarm for not putting out the fire. Fix the code, not the alarm.
Q: What's the practical implication for my team?
A: Focus on improving code review velocity, writing better unit tests, and clarifying requirements before development starts. Track where time is actually spent in your release cycle. You'll likely find that the bottleneck is not QA but something upstream—like waiting for code review or flaky builds.
Q: Is it ever a good idea to eliminate QA entirely?
A: No. QA provides an independent perspective that catches things developers miss. The problem isn't the QA function—it's the culture of blaming them for systemic issues. Remove QA, and you'll just find another scapegoat (like the product manager or the operations team). The root causes remain.