Our most-read post ever on LinkedIn told a simple story: a PM told a QA engineer to close out a bug report, because the bug was inconvenient for the release timeline. The bug was real. The instruction to close it wasn’t about the bug being wrong, it was about the bug being awkward.
The most common pushback in the comments was some version of: isn’t this just old-school QA-versus-dev silos with extra steps? If QA can’t be overruled, aren’t you just recreating the adversarial setup companies spent a decade trying to get rid of?
It’s a fair question, and the answer depends on what “independent” actually means here, because it’s easy to hear it wrong.
QA isn’t inspecting against a checklist
Independent QA, done properly, isn’t “does this match the ticket.” That’s inspection. It’s useful, but it’s not the interesting part of the job.
The interesting part is exploratory risk discovery: what could go wrong here that nobody thought to write down. Nobody specs out every edge case in advance. A good QA engineer goes looking for the ones that weren’t specced, because those are exactly the ones that surprise users in production.
A finding isn’t a veto
Here’s the part that gets missed in the “isn’t this a silo” objection: QA doesn’t have the power to block a release, and it shouldn’t.
QA’s job ends at surfacing the risk clearly and completely. What happens next, ship anyway, delay, fix now, fix later, is a business call. Sometimes shipping with a known issue is the right trade-off given the deadline or the severity. That’s a legitimate decision, and it belongs to whoever owns the release, not to QA.
So independence was never about QA outranking the PM. It’s about the finding reaching the PM intact, so the PM can actually make that call with real information instead of a rounded-off version of it.
The actual failure mode
Go back to the original story. The problem wasn’t a business decision to ship with a known bug. Plenty of teams make that decision every week, correctly. The problem was that the bug got silently closed, with no record, so nobody with the authority to accept that risk ever actually saw it.
That’s the difference that matters. “We know about this and we’re shipping anyway” is a decision. “Nobody knows about this and we’re shipping anyway” is an accident waiting to be discovered by a customer instead of a QA engineer.
Why this isn’t a silo
A silo means QA and the rest of the team don’t talk, each side just does its own thing and throws results over a wall. What we’re describing is close to the opposite: QA surfaces everything it finds, loudly and completely, specifically so an informed human can weigh in. The independence is about the finding not getting watered down or suppressed on its way to that person, not about QA working apart from the team.
If anything, silencing an inconvenient bug is the more isolating move. It cuts the decision-maker out of a decision that was theirs to make. Keeping the finding visible, even when it’s not going to change the release date, is what keeps QA and the business actually talking to each other instead of past each other.
You can read more about how we think about independent software testing on our services page.
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.
