1. Define quality
Agree what quality means for this product before arguing about tests. Pick the quality aspects that actually matter to your business and rank them.
Read the deep diveWhat is risk based software testing?
Risk based software testing is a test strategy approach in which the team identifies the product risks that matter, ranks them by likelihood and business impact, and then decides how each one will be mitigated. Testing becomes one mitigation among several — alongside monitoring, reviews, design changes, and the explicit decision to accept a risk.
The practical consequence is that coverage becomes deliberately uneven. A payment flow that fails silently is worth days of effort; an internal admin screen used twice a month usually is not. Because every choice traces back to a named risk, the strategy can be explained to product owners, auditors, and new team members without a hundred-page test plan.
It is also not a one-off exercise. Risk changes when the product, the architecture, the team, or the market changes, so the risk map is something teams revisit rather than archive.
Why agile teams use it
Agile teams rarely have the time to test everything, and pretending otherwise produces a slow, brittle regression suite that nobody trusts. Risk based software testing makes the trade-off explicit and turns it into a team decision instead of a tester's private judgement.
- Sprint testing effort goes to the areas where failure actually hurts
- Coverage decisions become explainable to product owners and stakeholders
- Fewer low-value regression tests to maintain over time
- Whole-team ownership of quality instead of a testing bottleneck
- A shared risk map that new team members can read in minutes
- Test strategy that can be updated in a workshop, not a document rewrite
How to run it: the four RiskStorming phases
RiskStorming is a facilitated workshop format that turns risk based software testing into a session with a clear output: a prioritised, mitigated risk map.
2. Identify risks
For each important quality aspect, ask what could go wrong. Cross-functional input turns vague worries into concrete, named risks.
Read the deep dive3. Discuss solutions
Match each prioritised risk to a mitigation: a test, a monitor, a design change, a code review, or a deliberate decision to accept it.
Read the deep dive4. Deliver quality
Turn mitigations into work the team commits to, and revisit the risk map each release so the strategy keeps up with the product.
Read the deep diveRisk based software testing FAQ
What is risk based software testing?
Risk based software testing is an approach to testing where the team prioritises test and mitigation effort according to the likelihood and business impact of potential failures. Instead of trying to test everything equally, you identify product risks, rank them, and spend the most effort on the risks that would cause the most damage.
How is risk-based testing different from traditional test planning?
Traditional planning often starts from requirements and aims for broad, even coverage. Risk-based testing starts from what could go wrong and what that failure would cost, so the resulting strategy is deliberately uneven: heavy where risk is high, light or absent where risk is low.
How do agile teams apply risk based software testing?
Agile teams typically run a short collaborative risk session per feature, epic, or release, produce a prioritised risk map, and translate the top risks into test and mitigation tasks in the same backlog as the feature work. The map is revisited whenever the product or its context changes.
Who should take part in a risk-based testing session?
Anyone who holds part of the picture: testers, developers, operations or SRE, product, and where relevant security, support, and business stakeholders. Risk identification depends on different perspectives, so a session with only testers finds fewer risks.
How does RiskStorming relate to risk based software testing?
RiskStorming is a facilitated workshop format for doing risk based software testing. It gives the four phases a concrete structure with card decks and a board, so a team can move from 'what is quality here?' to a prioritised, mitigated risk map in a single session.