Risk-Based Testing Explained: Score Risks, Build a Matrix and Test What Matters

A release is due Friday. The team has three days and three hundred possible test cases. Testing everything equally means testing the payment flow with the same care as the colour of a settings icon. Risk-based testing replaces that with a deliberate choice: test first and hardest where failure is both likely and costly.

This is a process guide, so it contains no code that we ran. The scores in the worked example are illustrative, chosen to show the method, not measured from a real product.

What is risk-based testing?

Risk-based testing is an approach where the amount and order of testing are driven by product risk. A risk is something that could go wrong, such as a feature failing, data being corrupted or a page being too slow. Each risk is assessed on two dimensions: how likely it is to happen, and how severe the impact would be. The combination decides how much testing it deserves.

It is not a separate test type, like performance or security testing. It is a way of planning and prioritising all of them, and it fits naturally into a test strategy.

Why it works

• Time is always limited. Prioritising by risk makes sure the most important checks happen even if time runs out.
• Bugs are not evenly spread. Complex, new and frequently changed code tends to hold more defects.
• Impact is not equal. A wrong total at checkout and a misaligned footer are both bugs; only one loses money.
• It makes trade-offs visible. Stakeholders can see what was tested deeply and what was accepted as lower risk.

The five steps

1. Identify risks with the team.
2. Score each one for likelihood and impact.
3. Prioritise using a risk matrix.
4. Plan and test with depth matched to risk.
5. Review after testing and after release, and update the scores.

Step 1: identifying risks

Gather testers, developers and someone who understands the business, such as the product owner. Walk through features, user journeys and recent changes, and ask what could go wrong. Useful prompts:

• Where would a failure cost money, break the law, or lose data?
• What changed in this release, and what does it touch?
• Which areas have had many bugs or incidents before?
• What depends on third parties, such as payment gateways or APIs?
• What is new technology or unfamiliar code for the team?
• What happens under load, on slow networks or on older devices?

Write each risk as a short, specific statement, such as “Order total is wrong when a coupon and free shipping apply together”, not just “Checkout”.

Step 2: scoring likelihood and impact

A 1-to-5 scale is common because it is quick to agree on:

Risk score = likelihood × impact, giving 1 to 25. Likelihood rises with complexity, amount of change, past defects and developer unfamiliarity. Impact rises with the number of users affected, money involved, safety, data and legal exposure. Agree definitions in advance so that a “4” means the same thing to everyone.

Step 3: the risk matrix

              Impact →
              1    2    3    4    5
Likelihood 5  5   10   15   20   25
           4  4    8   12   16   20
           3  3    6    9   12   15
           2  2    4    6    8   10
           1  1    2    3    4    5

Plot each risk on the grid. Scores in the top-right corner are your priorities; scores in the bottom-left can receive light checks. Many teams colour the bands: for example, 15 to 25 high, 8 to 14 medium and 1 to 7 low. These thresholds are a convention, not a standard, so adjust them to your context. Some teams use a simpler 3 × 3 grid of low, medium and high, which is often enough.

Step 4: mapping risk to test depth

Depth means more than number of test cases. For high risks, consider stronger techniques, such as boundary value analysis and decision tables, independent review of test design, testing on more devices and environments, and monitoring after release.

Step 5 in practice: a worked example

An online shop is releasing a new coupon feature. The team lists and scores risks (illustrative scores):

The plan follows directly. The total calculation gets detailed tests for every combination of coupon, shipping rule and tax, automated unit tests, and an exploratory session. The usage limit gets concurrency tests, since two simultaneous checkouts are the likely way to exceed it. The gateway timeout gets a few failure-injection tests, because its impact is severe even though the score is medium. The banner gets a glance on one tablet. If time runs out on Thursday, it is the banner that waits, by deliberate choice.

Where risk data comes from

Scores start as informed judgement, but data makes them better:

• Defect history: modules with many past bugs. Our bug life cycle guide covers tracking these.
• Code churn: files changed most often in version control.
• Production incidents and support tickets.
• Usage analytics: the most used journeys have the most users at risk.
• Test coverage gaps: areas with little automated coverage; see code coverage explained.

Risk-based testing in agile and CI

In short sprints, a full workshop each time is too heavy. A lighter version works well: discuss risks during refinement, tag stories as high, medium or low risk, and agree the testing depth as part of the definition of done. In CI, run tests for high-risk areas on every commit and broader suites less often. The test pyramid helps decide the level: push high-risk logic into fast unit tests where possible, and keep end-to-end tests for the riskiest user journeys.

Common mistakes

• Scoring alone. A tester working alone misses business impact and technical complexity. Score as a group.
• Scoring once. Risks change as code changes. Review the list every release.
• Treating low risk as “no testing”. Low risk means lighter testing, not none.
• False precision. Arguing whether something is 12 or 15 wastes time; the ranking matters more than the exact number.
• Hiding the trade-offs. Report which risks were tested lightly or not at all, so stakeholders can accept them knowingly.

Reporting risk coverage

A test report organised by risk is far more useful to decision-makers than a raw pass count. For each risk, show its level, what testing was done, the result and anything still open:

The example rows are illustrative. The point is the format: anyone can see at a glance that the most dangerous areas were tested thoroughly, which risks remain, and what was consciously left out. “Ready to release?” becomes a discussion about specific risks, not a feeling.

Final thoughts

Risk-based testing is common sense made explicit: spend the most effort where failure is most likely and most costly. List risks with the whole team, score likelihood and impact on a simple scale, plot them on a matrix, and match test depth to the result. Then revisit the scores each release, using real defect and incident data to make the next round sharper.

Frequently asked questions

Keep learning