Risk-based testing: what to skip when the deadline moves
The release was planned for Friday. On Wednesday, the deadline moves to Thursday morning. You have two days of testing left and half a day to do it in.
You cannot test everything. You never could — but now it is obvious.
Risk-based testing is the honest answer to this situation. Instead of testing whatever comes first and running out of time somewhere random, you rank everything by risk, test from the top, and let the cut line fall wherever time runs out. Whatever gets skipped is skipped on purpose, in writing.
Short version
- Risk = how likely something is to break × how bad it is if it does.
- Score every area 1–3 on both, multiply, sort, test from the top.
- Recent changes and past bug hotspots raise likelihood.
- Money, data, and reputation raise impact.
- Whatever falls below the cut line gets written down, not forgotten.
The idea in one table
Risk has two ingredients:
- Likelihood — how likely is this area to be broken right now?
- Impact — if it is broken, how much damage does it do?
Score each from 1 (low) to 3 (high). Multiply. Sort.
| Area | Likelihood | Impact | Risk score |
|---|---|---|---|
| Checkout (redesigned this sprint) | 3 | 3 | 9 |
| Payment provider upgrade | 2 | 3 | 6 |
| CSV export (new feature) | 3 | 2 | 6 |
| Login (unchanged for months) | 1 | 3 | 3 |
| Profile settings (unchanged) | 1 | 2 | 2 |
| Help pages (static content) | 1 | 1 | 1 |
With half a day, you test the 9 thoroughly, the 6s well, smoke-test the 3, and consciously skip the rest.
That is the entire method. The skill is in scoring honestly.
Scoring likelihood
Likelihood is about change and history, not fear. Ask:
Did it change this release? Changed code breaks. Unchanged code mostly does not. This is the strongest single signal — get the list of changes from the team or the release diff.
Does it depend on something that changed? A payment library upgrade touches everything that takes payment, even if "checkout code" did not change.
Has it broken before? Bug history repeats. An area with five bugs in the last three months earns a 3 regardless of what changed. Your bug tracker already knows your hotspots — search it.
Is it complex? Date logic, money calculations, permissions, anything with many states. Complexity breeds bugs.
Is it new? New features have no survivors' record. Default them to 3.
A simple rule of thumb: changed or new = 3, depends on a change = 2, untouched and stable = 1.
Scoring impact
Impact is about consequences, and it belongs partly to the business, not just to QA. Ask:
Does it touch money? Payments, invoices, pricing, refunds. Automatic 3.
Can it lose or corrupt data? Automatic 3.
How many users pass through it? Login and the home page affect everyone. An admin-only settings page affects a handful.
Is it visible? A broken homepage banner is trivial in function and severe in reputation.
Is there a workaround? A failure users can route around scores lower than a dead end.
If you are unsure about an impact score, ask the product owner. They know which customer is mid-renewal and which feature was promised in the sales demo. That thirty-second question is the difference between your risk model and the business's actual risk.
Matching test depth to score
Do not treat testing as on/off. Match depth to score:
| Risk score | Depth |
|---|---|
| 8–9 | Full test cases + exploratory session + edge cases |
| 5–7 | Main flows + the known nasty cases |
| 3–4 | Smoke test: does the happy path work at all? |
| 1–2 | Skip, and say so |
This is where the time savings actually come from. Most teams under deadline do not skip low-risk areas — they test everything shallowly, which spends real time on help pages while checkout gets twenty minutes.
Write down what you skip
This is the step that makes risk-based testing defensible instead of just fast. Three lines per skipped area:
Skipped: Profile settings, help pages, DE/FR localisation. Reason: No changes this release; no bug history; time cut to 0.5 days. Risk accepted by: A. Khan (release owner), 06 May.
Put it in the release sign-off. When something skipped does break — occasionally it will — the record shows a reasonable decision made with the information available. That is the difference between a process failure and a bad roll of honest dice.
The same record, kept over several releases, is also your best argument for more testing time: "Here are the four areas we have skipped three releases in a row."
A 30-minute version for real emergencies
When even scoring feels like too much time:
- List what changed. (5 min — from the release notes or the developers)
- Circle anything touching money, data, login, or the main user flow. (2 min)
- Test the circled items first, main flows only. (most of your time)
- Smoke the golden path end to end once — sign up, do the core thing, pay, log out. (10 min)
- Write the three-line skip note. (3 min)
Not elegant. Far better than starting at the top of the test suite and running out of time at the letter M.
Keeping found bugs fast under pressure
Risk-based testing compresses testing time, which means bug reporting has to be fast too. A bug found in a deadline crunch still needs steps, environment, and evidence — a vague ticket written in a hurry costs more time than it saves when the developer bounces it back.
This is exactly the situation where automatic capture earns its keep: reporting straight from the browser with Crosscheck attaches the screenshot, console, network log, and environment in one step, so a crunch-time bug report takes a minute without losing the evidence.
Frequently asked questions
Is risk-based testing just an excuse to test less? No — it is a way to admit that testing was always incomplete and choose the incompleteness deliberately. Testing "everything" was never true; the only question is whether the gaps are chosen or accidental.
Who should set the scores? QA proposes, with developers correcting likelihood (they know what changed) and product correcting impact (they know what matters). Fifteen minutes together is enough for most releases.
Should scores be recalculated every release? Likelihood, yes — it follows the changes. Impact scores are mostly stable and only need revisiting when the product or its users change.
What if everything scores high? Then the release is too big to test in the time given, and the scoring table is your evidence. Take it to the release owner: cut scope, add time, or accept named risks.
Does this replace regression suites? No. Automated regression keeps covering the stable areas cheaply, which is exactly what lets your limited human time concentrate on the high-risk ones.
Add to Chrome