Our posts on QA independence pulled in some of the best comments we’ve gotten, because people kept adding their own version of the same story. A few of those deserve more than a comment thread. Here are four, and what each one actually illustrates.
1. “Don’t mark it blocked, it screws with our metrics”
One commenter described being told exactly that: a real, blocking issue was flagged, and the instruction back wasn’t to fix it, it was to relabel it so a dashboard number kept looking good.
The bug didn’t get less blocking because it got a different label. What changed was who got to see the truth. A metric that only looks healthy because the inputs were massaged isn’t a metric anymore, it’s a story someone is telling themselves.
2. Shooting the messenger
Another reader described a PM telling a QA person that logging 300 legitimate bugs “made the product look bad.” Not the bugs. The accurate documentation of them.
This is the clearest version of a pattern that shows up constantly: treating the discovery of a problem as the offense, instead of the problem itself. It trains people to find fewer bugs, or report fewer of the ones they find. Neither makes the product better. Both make the next incident a surprise instead of a known risk.
3. “Don’t do that”
A third commenter mentioned once suggesting that developers shouldn’t be the sole testers of their own code, and being told, flatly, not to bring it up again.
The logic for independent testing isn’t subtle. Nobody is equally good at spotting flaws in something they just built themselves, that’s not a criticism of developers, it’s just how attention works. The resistance to saying that out loud, even when everyone privately knows it, is its own small data point about how fragile independence can be inside a team.
4. The natural experiment
The last one is the sharpest. A QA person refused to report into the Dev Manager, on the correct reasoning that reporting to the person whose work you check undermines your ability to check it honestly. They eventually left. The project collapsed not long after.
We’re not claiming the org chart alone caused the collapse. But the fact that losing the person who insisted on that independence, and the independence itself, coincided with the project falling apart is worth sitting with. It’s a live example of what the reporting-line argument is actually protecting against.
The throughline
None of these four are about bureaucracy for its own sake. Refusing to fudge a metric, refusing to punish accurate reporting, refusing to be the sole check on your own work, refusing to report to the person you’re supposed to be checking: all four are the same instinct wearing different clothes. They’re what keeps a real problem visible long enough for someone with the authority to actually decide what to do about it.
Break any one of them and the bugs don’t go away. They just stop being visible until a customer finds them instead.
If you want to talk about how to structure QA so it stays independent in practice, not just on paper, that’s the work we do. More on our testing services page, and our take on the underlying philosophy is in our piece on the 7 principles of testing.
Built by BetterQA.
Need help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
