QA Process
Risk-Based Testing.
You can't test everything, so test what hurts most when it breaks. Risk-based testing scores each area by impact and likelihood, then spends your time where failure is both probable and painful.
When to use it
Use this whenever testing everything isn't possible — a tight release window, a large product, or a regression suite that no longer fits the cycle. It's how you decide what to test deeply, what to smoke, and what to skip on purpose.
Who uses it
Senior QA and leads who plan coverage and defend it, QA engineers prioritising their own test design, and the product and engineering partners who help score what's actually risky.
On this page11 sections
WHAT IS RISK-BASED TESTING
Risk-based testing is an approach where the depth and order of testing follow risk rather than habit. Instead of trying to cover everything equally, you rank each feature or change by how likely it is to fail and how badly that failure would hurt, then concentrate effort on the top of that list.
It doesn't mean skipping testing carelessly. It means making the trade-off explicit: high-risk areas get deep, varied testing; low-risk areas get a light check; and you can say exactly why each area got the attention it did.
WHY TEAMS USE IT
Time and people are finite, and most products are far too large to test exhaustively every release. Risk-based testing is how teams get the most quality signal from the hours they actually have, instead of spreading themselves thin and testing everything shallowly.
It also makes coverage decisions defensible. When a stakeholder asks why a low-traffic admin screen wasn't regression-tested before a launch, "it scored low on impact and hasn't changed in six months" is an answer; "we ran out of time" is not.
RISK = IMPACT × LIKELIHOOD
Risk has two dimensions, and you need both. Impact is how much damage a failure causes — lost revenue, exposed data, blocked users, reputational harm. Likelihood is how probable that failure is — driven by complexity, how recently the code changed, and its defect history.
Multiply them. A high-impact area that almost never breaks may still warrant attention; a low-impact area that breaks constantly usually doesn't. The areas that score high on both — painful and probable — are where risk-based testing tells you to look first.
HOW TO IDENTIFY RISKS
Before you can score risk you have to name it. Walk the product feature by feature with engineering and product in the room, and ask of each: what could go wrong here, and what would it cost us? These categories are a useful checklist so nothing gets missed.
Risk categories to weigh
Business criticality — how central the area is to what the product is for (checkout on a shop, search on a marketplace).
Customer impact — how many users a failure touches, and how visibly.
Financial impact — direct revenue or cost exposure if it fails (payments, billing, pricing).
Security risk — whether a failure could expose data or allow unauthorised access.
Compliance risk — whether a failure breaches a legal or regulatory obligation.
Technical complexity — how intricate the code or integration is, which raises the chance of defects.
Change frequency — how recently and how often the area has changed; fresh code is riskier code.
Defect history — whether this area has a track record of breaking.
Integration dependency — how many other systems it relies on or feeds, where failures cascade.
Data sensitivity — how confidential or irreplaceable the data it handles is.
HOW TO SCORE RISKS
Turn the categories into a number so areas can be compared. A simple, durable scheme is to rate impact 1–5 and likelihood 1–5, then multiply for a risk score from 1 to 25. The point of the number isn't false precision — it's forcing a consistent conversation across the whole product.
Score as a small group, not alone. QA brings defect history and test insight, engineering brings complexity and change data, and product brings business and customer impact. A score three people agreed on survives scrutiny far better than one you set by yourself.
HOW TO DECIDE TEST PRIORITY
Sort by score and draw bands. High-scoring areas get deep coverage — multiple test types, edge cases, negative paths, and a place in every regression run. Mid-scoring areas get core happy-path and key negative cases. Low-scoring areas get a smoke check, or a documented decision to skip.
Make the bands a plan, not a vibe. Write down which areas are High, Medium, and Low and what "deep", "core", and "smoke" mean for each, so anyone picking up the work tests to the same bar — and so the plan can be reviewed when risk changes.
EXAMPLE RISK MATRIX
| Risk | Impact | Likelihood | Score | Test priority |
|---|---|---|---|---|
| Payment fails after checkout | 5 | 4 | 20 | High |
| Button alignment issue | 1 | 2 | 2 | Low |
| User can access another account | 5 | 3 | 15 | High |
RISK-BASED TEST PLANNING EXAMPLE
A team has two weeks to test a release touching checkout, a new wishlist feature, and a copy change on the help page. Treated equally, that's a lot of shallow testing. Scored for risk, the plan writes itself: checkout is impact 5 (revenue) and likelihood 4 (it changed), score 20 — High; wishlist is impact 3 and likelihood 4 (brand new), score 12 — Medium; the help-page copy is impact 1, likelihood 1, score 1 — Low.
So checkout gets the bulk of the fortnight: functional, payment-provider variations, negative paths, cross-browser, and full regression. Wishlist gets solid happy-path plus the key error cases. The help-page change gets a two-minute visual check. Same two weeks, but the effort now matches where a failure would actually hurt — and the plan says so on the record.
RISK-BASED REGRESSION EXAMPLE
A growing regression suite has crept to 600 cases and no longer fits the release window. Rather than run a random subset, the team scores each suite area by risk. High-risk areas — login, checkout, payments, permissions — run every release, no exceptions. Medium-risk areas run on a rotation or when their code is touched. Low-risk, stable areas drop to a monthly full pass with a smoke check in between.
The result is a regression run that fits the cycle and still protects what matters. When something does slip through in a low-risk area, the team revisits its score instead of quietly re-adding everything — the suite stays sized by risk, not by fear.
COMMON MISTAKES
Scoring risk once and never revisiting it.
Risk moves. Re-score when code changes, defects cluster, or usage shifts — a stale matrix protects last quarter's product, not this one.
Only weighing impact and ignoring likelihood.
A catastrophic-but-impossible failure can outrank a constant nuisance in a pure-impact model. Always multiply impact by likelihood.
Scoring risk alone, as QA.
You don't have the full business or complexity picture. Score with product and engineering so the numbers — and the coverage choices — hold up.
Treating "low risk" as "never test".
Low risk means a light, documented check, not a blind spot. A smoke test still catches the obvious break.
Hiding the matrix in QA's head.
Write the scores and the resulting coverage bands down. The value is in a decision others can see, question, and trust.