Risk-based testing: prioritise the tests that matter most
Risk-based testing orders tests by the likelihood and impact of failure. A transparent scoring model built from priority, recent failures, changes and coverage gaps.
Risk-based testing means running the tests most likely to find important problems first. A practical score adds points for business priority, a recent failure, changes since the last run, never having been run, a failing linked requirement and flakiness; you then run cases from the highest score down until time runs out.
The problem risk-based testing solves
There is rarely time to run every test before every release. When you must choose, the choice should be deliberate: run the tests most likely to find important problems first. That is risk-based testing.
Risk has two parts:
- Impact: how bad it would be if this behaviour broke (business priority).
- Likelihood: how likely it is to be broken right now (recent failures, recent changes, no history).
A transparent scoring model
Opaque “AI risk scores” are hard to trust. A points-based model anyone can read works better. This is the model TestPlum uses; adapt the weights to your context.
| Signal | Why it raises risk | Points |
|---|---|---|
| Priority critical / high / medium | Impact if it breaks | 40 / 25 / 10 |
| Last result failed or blocked | It is broken, or was recently | 35 |
| Edited since last execution | The test or behaviour changed | 25 |
| Never executed | No evidence at all | 20 |
| A linked requirement is failing | The area is known to be unstable | 15 |
| Flaky score of 0.3 or more | Results here are unreliable | 10 |
A critical case that failed last time scores 75; a low-priority case that passed and has not changed scores 0. Sort by score and run from the top.
Running a risk-based cycle
- Score every case in scope.
- Cut the list at the time you have; for example the top 150 cases for a one-day regression.
- Run them, highest score first, so the most important information arrives earliest.
- Re-score after fixes land; retested failures drop and newly edited cases rise.
- Report what was not run. Untested cases are accepted risk, and the release decision should say so.
Keep it explainable
For every selected case, show why it was selected: “critical priority + failed last run”. People accept a prioritised list when they can see its reasons, and they can challenge a weight that does not fit.
Where it fits
Risk-based selection decides what to run first. The release readiness checklist decides whether the result is good enough. Together they make a short test window predictable. TestPlum shows each case’s risk score with its reasons and starts a run of the riskiest cases in one click; see reports and release readiness.
Frequently asked questions
What is the difference between risk-based testing and regression testing?
Regression testing re-runs existing tests to catch breakages. Risk-based testing decides the order and subset of those tests when you cannot run all of them, putting the riskiest first.
How do you measure risk for a test case?
Combine impact signals such as business priority with likelihood signals such as recent failures, recent edits, no execution history, failing requirements and flakiness. Keep the formula visible so everyone can see why a test was chosen.