QA Is Risk Management
A few years ago I wrote about how a long pandemic shower helped me realize that software testing is really just collecting information. That clicked for me.
But the more I’ve worked in QA since then, the more I’ve realized that definition only answers what testers do — not why it matters.
Here’s where my thinking has landed:
QA is the practice of managing risks to software quality throughout the software development lifecycle.
Not finding bugs. Not running test cases. Managing risk.
Bug Count Is the Wrong Metric
Early in my career I worked for a testing vendor. The model was simple: a client hands you a build, you go find bugs. More bugs meant more value. High severity bugs were even better. App crashes were mouthwatering — every tester on the platform wanted one.
And we found them. Plenty of them.
In one enormous weekend test cycle our team of thirty testers proudly presented almost a hundred bugs. It didn’t stop the client from finding bugs we’d missed that delayed their release though. You could argue you can’t find every bug, and you’re right. But that’s exactly the point. A long bug list doesn’t give stakeholders confidence. If anything, a hundred bugs makes me more worried about a release than zero would.
While we were busy logging bugs, nobody was challenging ambiguous requirements upfront. Nobody was anticipating missed scenarios before they became bugs. Nobody was asking whether entire areas of the app had even been touched. The client got a long list of defects and probably felt like they were getting something — but they had no real picture of whether the rest of the app was working.
Bug count isn’t a complete picture. It never is. When you define QA as “finding bugs,” you optimize for the wrong thing. A team can file hundreds of tickets and still ship something that hurts the business — because the real risks were never on the table.
What Managing Risk Actually Looks Like
When I say QA manages risk, I mean four things.
Identifying risks early. The earlier you surface a potential problem, the cheaper it is to fix. By the time something shows up in production, you’re doing damage control, not QA.
Assessing which risks actually matter. Not every risk deserves the same attention. Likelihood and impact both factor in. A bug that affects 0.1% of users on a legacy browser is a different conversation than one that breaks checkout for everyone.
Building mitigation strategies — with the team. QA spots the risk; the team figures out how to address it. This isn’t something you do in a corner and hand over. It’s a collaboration.
Communicating it to the right people. This one is underrated — and it’s where I think QA practitioners most often let themselves off the hook. Raising a risk always feels like delivering bad news. That pressure is real, and I’ve felt it. But seeing a bug and pretending you didn’t is the cardinal sin of QA. If you’re afraid to surface what you found, you’re not managing risk. You’re just hoping.
Quality Isn’t a Fixed Target
One thing I’ve had to let go of is the idea that there’s a universal standard of quality to enforce. There isn’t.
A startup shipping an MVP operates under completely different quality thresholds than a hospital deploying safety-critical software. QA’s job isn’t to impose a standard — it’s to help the organization figure out what quality means for them, and then protect that.
That’s an advisory role, not a gatekeeper role. QA doesn’t own the ship/no-ship decision. But we do equip the people who do with the right information.
Working internally changed that. Suddenly I was at the table influencing deployment decisions, and I had to learn to be disciplined about it. I wouldn’t push back hard on a release, but I noticed how much my language shaped the room — a careful word choice here, a hedged summary there, and I was subtly signaling an opinion I wasn’t supposed to have. It’s something I still watch in myself. My job is to give stakeholders an objective picture of the risk, not to nudge them toward a decision.
When QA Is Actually Working
The goal isn’t zero bugs. It’s making sure stakeholders have what they need to avoid bad outcomes.
Bad software has real consequences — customer churn, reputational damage, incidents that cost money to clean up. QA’s job is to reduce that exposure before it happens, not document it after.
That means being present throughout the whole lifecycle — from requirements and design through development and release — not just at the end as a final check. By the time a risk shows up in production, it’s too late to manage it.
When QA is doing its job well, risks are on the table early. Decisions are better informed. The team knows what they’re protecting — and why. That’s my current philosophy, anyway. Until I get my next great shower thought.
