ON THIS PAGE ▾
Every team has more to test than time to test it. The question is never whether to prioritise, but whether you do it deliberately. Without a method, priority tends to follow whatever is newest, loudest or easiest, and the quiet, expensive failures slip through.
Risk-based testing is the deliberate version. You rank what could go wrong by how likely it is and how much it would cost, and you let that ranking decide where testing effort goes. It does not make anything cheaper by magic; it makes the trade-offs visible and defensible.
A simple model
You do not need a complicated framework. List the features, flows and integrations you could test, then score each on two questions.
Impact: what would a failure cost?
- Money: lost revenue, wrong charges, refunds.
- Data: loss, exposure or corruption of customer or business data.
- Safety and legal exposure, where relevant.
- Reputation and trust, and how many users would be affected.
- Recovery: how hard would it be to put right?
Likelihood: how likely is it to break?
- How often does this area change?
- How complex is it, or how many systems does it touch?
- Is any of it new technology for the team?
- Has it failed before?
- Does it depend on third parties you do not control?
Score each from one to three (low, medium, high) and look at the combinations. The numbers are only a way of making a conversation concrete; the point is the discussion they provoke, not the arithmetic.
From scores to a test plan
- List the candidates. Features, user journeys, integrations, and the non-functional concerns such as performance and accessibility.
- Score impact and likelihood together, in a short session with product, engineering and QA in the room.
- Decide the depth. For the highest-risk items, combine scripted checks, automation for what repeats, and exploratory testing for what scripts miss. For the lowest, a smoke check may be enough.
- Name the gaps. Record the areas you have chosen to test lightly or not at all, and why.
- Share the plan so everyone agrees what "tested" means for this release.
A worked illustration helps. Imagine a retail product: checkout and payment score high on impact and medium on likelihood, so they get deep, repeatable coverage. A rarely used account-settings page changes often but costs little when it breaks, so it gets a light regression check. A new third-party shipping integration scores high on both, so it gets focused integration testing and a failure-path review before anything else.
Common pitfalls
- Scoring theatre. Spending longer on the spreadsheet than on testing. Keep it short.
- Everything is high. If every item scores high, the exercise has told you nothing. Force a ranking.
- Ignoring unknowns. Areas nobody understands are a risk in themselves; flag them rather than guessing a low score.
- Set and forget. A plan from six months ago reflects a different product.
Where AI can help, and where it cannot
AI is useful at the likelihood side: it can read a code change, a defect history or a set of recent tickets and point to the areas most likely to be affected. It is poor at the impact side, because what a failure costs depends on your business, your customers and your commitments. That judgement stays with people.
THE UPDOER APPROACH
How UpDoer approaches this
Risk mapping is the second step of our methodology, and it shapes every step after it. We gather everything that changed, including the code diff where we have it, and use AI to score where a release is most likely to break. A QA engineer then decides what a failure would cost this particular business; the AI's score is an input, never the answer. The resulting strategy says what is automated, what stays manual and what is explicitly out of scope for this cycle.
This thinking underpins our Functional Testing, Regression Testing and Integration Testing work. For the full picture, see how we work.
If you would like a second pair of eyes on your own situation, schedule a meeting and tell us about your product, your delivery process and the quality questions you are facing.