Testers Don't Mitigate Risks
This week, I had an interesting conversation where someone claimed, "the QA (quality assurance) mitigated the risk." When I asked for clarification, they couldn’t clearly explain how this was achieved. This reinforced the point I’ve been trying to make—perhaps my reaction a bit too bluntly (for which I apologized, blaming my Dutch directness).
I want to take this opportunity to explain my perspective:
As a tester (whether your title is QA, software tester, or something else), you play an important role in the process of risk management. Your primary responsibility is to gather information, provide feedback and evaluate about what you uncover (during testing). However, you have limited time and resources, which means you must prioritize your efforts.
Testing and Risk Identification
The areas you focus on are often chosen by where you expect risks to be. These expectations might be based on factors like:
These expectations guide your testing, but they don’t eliminate risks. Instead, they help you identify and evaluate them. Through your findings, you provide data and information on:
However, discovering or identifying a risk doesn’t make it larger or smaller—it simply improves understanding. Testing is about creating visibility, not mitigation.
Risk Mitigation Requires Action
To mitigate a risk, specific actions need to be taken. Mitigation involves decisions and steps based on the information you provide. For example:
Recommended by LinkedIn
At this point, the team (or the product owner, or a business representative) decides what to do with this information. These decisions form the core of risk mitigation, which typically follows one of four strategies:
Once these steps are underway, risk mitigation is in progress.
Mitigation is a Continuous Process
Risk mitigation is never fully complete. Every change, fix, or update introduces the potential for new risks or changes in the nature of existing ones. Risk management is a dynamic, ongoing process.
This is why I’m often surprised when testers say they are "done" and hand over a report claiming, “There are no more risks.” Unless you can predict the future (in which case, you should definitely buy a lottery ticket!), risks can never be completely eliminated.
Final Thoughts
To summarize: gathering information through testing is just the first step in understanding risks. It is an essential contribution, but it is not the same as mitigating risks. Mitigation requires decisions and actions that extend far beyond what testers alone can provide.
I hope this explanation clarifies why testers, while vital to the (quality) process, do not mitigate risks. Instead, they empower others to make informed decisions about how to handle them.
What a great article!
Tester
1yThis message 'testers don't mitigate risks' is also risky if people use it without the skills to explain why and what we do to non-testers, to people who hire testers to do just that, 'get fewer bugs in production'. The title should reflect what the article is saying 'testers alone don't mitigate risks', otherwise we end we going from one pole to the other and not meeting in the middle (which I'm assuming is where we want to). I'd rather say 'Yes, I can help you mitigate risks, this is how this is what I can do' and leave the other person to conclude that my testing service alone is not enough to solve the problem. My point is that the idea (message) is one thing, and how we deliver it is also very important. Absolut language doesn't help too much with conveying the message because you lose attention and credibility from the start of the conversation if you are trying to convince or change someone's line of thinking.
There is *one* kind of risk that testers can mitigate to some degree: the risk of oblivion to problems that would likely go unnoticed. Otherwise, I'm with Fiona: "We really don’t need the self-aggrandizement of falsely believing we mitigate risks." Self-aggrandizement is a big problem in the testing (cf. "quality assurance" and "quality engineering") world.
Not sure I agree. (Not that agreement or disagreement really adds much value at this point, as I'm sure we align on the ideas, if not so much the phrasing.) Do traffic lights mitigate the risk of traffic accidents? They only provide information, right? Do developers solve customer problems? They only write code, right? Do testers mitigate risks? They provide information. If they're worth their salt, they'll also advocate for mitigating action. And if that information would otherwise not be uncovered or acted upon, I'd say they've attributed to mitigating said risk. Just like the foot of the driver, the brake of the car, the white line on the road. Testers are not the only actors, but they're crucial part. Take up that responsibility.
I'd like to point out a different perspective. Risk management is about what we perceive as a risk. Based on our knowledge, understanding of the problem and experience, we (testers with the project team) set a value to the likelihood of the risk to become an issue. By running tests that either expose a defect or verifying the functionality is working as expected, we change the perception of the likelihood. This activity, to my understanding, is risk mitigation.