How to identify risks which matter most for testing
This post is devoted to identifying and quantifying risks before deciding what to test. That means collecting stakeholder fears, converting them into explicit risk statements, and estimating their impact. The output is a prioritized list of risks, not a test plan.
In most of the companies I worked for, testing efforts usually started quite simply: someone opens a ticket tracker or a test management tool and starts writing test cases. What system behaviour to verify, which flows to cover, which edge cases to include.
However, the more important part to discuss and align on first is: what could go wrong, and what would it cost?
Without figuring that out, you're designing a testing portfolio without knowing what you're investing against. You might end up testing what's easy to test rather than what matters most.
Two purposes, not one
So how do you figure out what could go wrong? You ask people. And what you get back isn't structured risk data: it's fears and concerns. Managers worry about revenue. Engineers worry about fragile integrations. Support worries about the same complaints every sprint. These fears are unstructured, emotional, sometimes vague, but they signal real uncertainty about real risks.
Gathering fears at the start of the process does two things.
It gives you signals for further analysis: once you know what stakeholders are worried about, you can convert those fears into explicit risks, quantify impact, and justify testing investments in concrete terms.
It also produces alignment. Managers, engineers, product owners, and operations often have completely different fears, and they often don't know each other's concerns. Surfacing fears in the same room forces a shared picture of what matters. That shared picture is worth building before you write a single test case.
Who to ask, and what to ask
Different stakeholders carry different fears because they sit in different places relative to failure.
Managers worry about business impact: revenue loss, regulatory penalties, customer retention, reputation. Engineers worry about technical failure: system complexity, integration brittleness, performance under load, security vulnerabilities. Operations worries about deployment stability and incident recovery. Support teams know the failure patterns that actually reach users.
You need all of these perspectives. The most common mistake here is only consulting technical teams and missing the business side entirely, or only consulting managers and missing the failure modes engineers already know about.
How you collect fears depends on your team and culture. In some organizations, structured cross-functional workshops work well: they surface assumptions and produce shared vocabulary quickly. In others, only one-on-ones get people to open up. In most, a combination works best: workshops for the group picture, one-on-ones for the things people won't say in a room, retrospectives and incident reports for recurring patterns. You know your company and your people better than any framework does.
One pitfall: rushing identification because it feels like preliminary work, not "the real work". It is the real work, and skipping it means you're estimating without a map.
From fear to risk statement
Fears are raw material. A fear like "I'm worried about performance" or "security keeps me up at night" is a signal, not an input you can act on.
To make a fear actionable, convert it into an explicit risk statement:
"If [condition], then [consequence] may occur, resulting in [impact]."
The template forces specificity. Let's take two concrete examples.
Take our insulin pump from Post 1. "I'm worried the dosing calculation could be wrong" is a fear. The risk statement is: "If a defect in the dosing algorithm produces an incorrect insulin dose, then a patient may receive a dangerous dose, resulting in serious harm or death". That's a reliability and functional suitability risk. The consequence is named. The impact is named. There's nothing vague left.
Now the internal CMS. "I'm worried content won't save properly" becomes "If a user submits a draft and the save operation fails silently, then content may be lost without a clear error message, resulting in wasted time and editor frustration". That's a usability risk. Consequence named. Impact named.
Same structure, but completely different stakes. Which, in my opinion, is exactly the point.
Quality check before moving on
Not every risk statement is ready for quantification. In my experience, having a simple checklist helps catch the weak ones early.
- Is the trigger observable? ("Peak load during checkout" is. "The system is under stress" is not.)
- Is the consequence measurable? ("Response times exceed 2 seconds" is. "Degraded performance" is not.)
- Is the impacted quality characteristic named?
- Is there an owner?
- Is there a detection signal: what would tell you the risk is materializing?
- Is it actionable: if its score rises, what decision does that drive?
If a risk statement fails any of these, refine it before moving to quantification. A risk that can't be detected and can't be acted on isn't a risk statement, it's still a fear.
Quantify the impact
Once risks are explicit and quality-checked, we can proceed and quantify their potential impact.
Everyone involved brings a different piece of the picture from their expertise. Engineers know how a risk would disrupt development: would it block the team, slow down deployments, eat into capacity for new features. Managers know the financial exposure: revenue loss, regulatory consequences, customer churn. Product owners know the user impact. Ops knows the operational fallout. The point is to get all of this into one conversation, in the same language, about the same risks.
Back to the insulin pump. Engineers flag that the production line hasn't been tested in extreme heat, and summers are getting hotter, so who knows, maybe insulin concentrations will start varying across batches. Clinical staff point out that incorrect dosing could lead to hypoglycemia, hospitalization, or death. Regulatory warns that a field defect means mandatory FDA reporting, possible recall, criminal liability. Business sees lawsuits, lost certifications, destroyed market trust.
Now the CMS. Engineers mention the editor has quirks with certain browsers. Users say formatting sometimes gets lost on save. Business shrugs: some people get annoyed, maybe they stop using it.
Same process, same questions. Completely different scale of consequences.
I find three-point estimation works much better than a single number here: optimistic, most likely, pessimistic. It makes uncertainty visible instead of hiding it behind a false-precision guess.
In my experience, two things help keep this step honest.
First, don't stop at "we don't know". You always have enough information to produce a rough range. Historical incidents, comparable failures at similar companies, domain expert judgment. A rough range with named uncertainty is more useful than silence.
Second, get everyone's expertise into the same conversation. If only engineers contribute, you miss the business picture. If only managers contribute, you miss what engineers already know about where the system is fragile.
What you have at the end
By the end of this process you have a list of explicit risk statements, not vague fears, each with a three-point impact estimate and documented stakeholder agreement on which risks matter most and why. To me, this is the most important outcome: you now have something concrete you can make decisions with, argue about, and revisit when things change. And you have people across the company who collaborated on building it and now better understand the risks the whole organization faces.
In the next article, we will categorize these risks by ISO 25010 quality characteristic and prioritize by risk exposure, so you know where to invest first.
The full research behind this series is at BeyondQuality.