This is the first post ever published on QA Redefined — March 21, 2009. The question it asks is still the right one.
QA gets treated as a cost center. Not because quality doesn’t matter, but because the name invites exactly the wrong framing — a checkpoint, not a discipline. Call something “assurance” and you’ve already conceded that someone else does the real work and you just verify it afterward.
The Checkpoint Model
Software quality assurance, as most organisations define it, is someone checking that other people’s work is acceptable before it ships. That definition — monitoring processes and methods to ensure quality — is so vague it can justify almost any resourcing decision. Which is exactly how most companies treat it: unclear on its importance, unclear on how to implement it, unclear on what it should cost.
Developers are under pressure to get code working. As soon as it does what they think was requested, they move on. They’re not wrong to do this — it’s the incentive structure. QA exists to catch what that pressure leaves behind.
Why It Fails
The failure mode is predictable. Management is either wary of the investment, doesn’t understand what QA actually does, or assumes it can be handled by whoever is available. The result: QA gets staffed with junior resources or repurposed analysts without the technical depth to test the infrastructure, the code, or the back-end systems that matter.
No structure. No long-term plan. Reactive, not proactive. Overwhelmed, not empowered.
QA becomes a bottleneck. Releases get delayed and management blames QA. Executive buy-in evaporates. The team gets cut or deprioritized. The cycle repeats.
What a Mandate Looks Like
For QA to be a contributor rather than a necessary evil, it needs real commitment — not goodwill. The sponsor has to understand what quality work actually costs, identify the roadblocks, build a multi-year budget, and define the ROI before the first hire is made. Not after things go wrong.
Done right, QA accelerates delivery, increases customer retention, and reduces the cost of defects found in production vs. development. The return is real. But it requires treating it as an engineering discipline with structure, methods, and processes — not as an afterthought staffed by whoever is available.
The name sets the expectation. Change the name and you change what people think they’re buying.
Seventeen years later, most of this is still true. The tools changed. The models changed. The organisational dynamic — QA as a cost to be minimized rather than a discipline to be invested in — is still the default. That’s what this site exists to push back against. The shift from quality assurance to quality engineering is where this starts. From QA to QE to SDET picks up from here.