The Role of QA Is Surfacing Risk
A few years ago I wrote about how a long pandemic shower helped me realize that software testing is really just collecting information about system behavior. 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 surfacing software quality risks, independently, throughout the software development lifecycle.
Not finding bugs. Not running test cases. Surfacing 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. 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 Surfacing Risk Actually Looks Like
When I say QA surfaces software quality risks, I mean four things.
Identifying risks early. The earlier you surface a potential problem, the cheaper it is to fix. That might mean reviewing requirements with product and engineering before a line of code is written, flagging ambiguity or scenarios nobody had considered yet. 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 and works with the team to figure out how to address it. And sometimes that means addressing the process, not just the bug. If QA keeps finding that every deployment to Staging breaks something major — an entire page down, a critical flow crashing — that’s a pattern worth raising. A post-deployment smoke check by the deploying engineer, or a simple automated test, would have caught it. QA’s job is to notice that, bring it to the team, and figure out what closes the gap. 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 making risk visible. You’re just hoping things work out.
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.
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, but 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 helped me understand that. Suddenly I was at the table influencing deployment decisions, and I had to learn to be disciplined about it. 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. Those decisions carry business and technical consequences that QA isn’t positioned to own. 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 finding one hundred bugs or making sure the team leaks zero bugs. It’s making sure stakeholders have the information 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 surface 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.
