Risk-based testing: how to prioritise by impact and likelihood
Risk-based testing helps a team decide what to examine first and how deeply when it cannot test everything equally. Priority comes not from which feature is newest or easiest to automate, but from the combination of a failure’s possible impact and its likelihood. The outcome should be an order of work, not another document filed away.
Why giving everything the same priority fails
A list of features labelled “high priority” is not yet a test strategy. Sign-in, report exports, and profile-picture changes may all matter, but their failures do not have the same consequences. If the team checks them in the same way, it may spend its time on many simple cases while a critical payment or data-recovery path receives only superficial coverage.
The opposite extreme is to rely only on past defects. A feature with no recorded incident is not necessarily safe; it may change rarely, or nobody may have noticed its failure yet. Risk therefore needs two views: what happens if the feature fails, and what makes it more likely to fail now.
Build a simple impact and likelihood matrix
Start with user journeys and important outcomes rather than individual screens. For each item, write down a specific failure, such as “the customer pays but no order is created” or “an operator can see another customer’s data”.
Then assess two dimensions on a simple low–medium–high scale:
- Impact: how many people the problem affects, whether it touches money or data, how quickly it can be corrected, and whether it has operational or regulatory consequences.
- Likelihood: how often the area changes, how many systems it connects, how complex it is, what its failure history shows, and how predictable its environment is.
Add one sentence explaining every rating. “High likelihood because interfaces between three services changed” is more useful than the number 9 on its own. When the team disagrees, the difference in reasoning often exposes a missing operational fact or an unclear requirement.
| Combination | Proportionate response |
|---|---|
| High impact, high likelihood | Verify at several layers, run checks after relevant changes, and define which failure stops a release. |
| High impact, low likelihood | Keep a thorough scenario and verify recovery; low likelihood must not conceal a severe consequence. |
| Low impact, high likelihood | Prefer a fast check at a lower layer or a representative sample. |
| Low impact, low likelihood | Limit coverage, examine it through exploratory testing, or consciously accept the risk. |
Turn risk into a specific testing decision
The matrix determines more than order. Make four decisions for every risk:
- What evidence you need. Is a calculation or API contract check enough, or must the complete user journey be exercised?
- Which layer gives the clearest result. The test pyramid helps avoid copying every combination into slow end-to-end tests.
- When to run the check. On every pull request, before a release, on a schedule, or only when the risky area changes.
- Who evaluates the outcome. Without an owner, even a red result can become background noise.
Do not try to automate every item in the red part of the matrix. Some rare or difficult-to-prepare situations are better examined manually, through a recovery exercise, or by reviewing the process. It also helps to state consciously what is not worth automating.
Keep the matrix alive
Review a rating after an incident, a significant architecture change, a new supplier, or a change in a feature’s business importance. Use evidence that supports decisions: failures in critical journeys, defects escaping to production, test instability, and time to restore service. A test count or pass rate without context belongs among the QA metrics that can mislead.
A risk rating is not proof that a defect will occur, nor a guarantee of complete coverage. It is a shared working assumption that should be explainable and challenged regularly.
What you gain
The team can explain why some checks run after every change while others are deliberately targeted. Critical risks receive more attention without growing the suite merely by adding cases. When the product or its operation changes, priorities can be revised for a stated reason rather than by instinct.
Next step
Choose your five most important user journeys. For each one, describe a specific failure, its impact, and the reasons behind its likelihood. Then connect each risk to an existing test, an owner, and a place in the release plan.