27 Oct 2026 Risk-based testing: how to pick a small regression set that covers what matters
In short: Risk-based testing means you spend your test effort where a failure would hurt most. For regression, you score each business flow on how likely it is to break and how bad that would be. Then you automate a small set that covers the top risks and runs every night. The rest gets lighter checks, less often.
A regression suite that needs all night to run feels safe. But big suites often hide a problem. So many tests fail for no real reason that nobody reads the results closely anymore. What protects a release is a set of tests that guards the things that would really hurt if they broke. Risk-based testing is a simple way to find those things. It helps you pick a small regression set your team can trust.
What is risk-based testing?
Risk-based testing is a way to decide what to test, and how deeply, based on risk. Risk has two parts here. The first is likelihood: how likely is it that this part of the system breaks? The second is impact: how bad is it for your customers or your business if it does? A part that changes often and handles money scores high on both. A settings page that few people use scores low. You test the high-risk parts first and most deeply. You test the low-risk parts lightly, or less often. The idea is not new. Test methods such as TMap and the ISTQB syllabus both build on it. For a regression set, it gives you one clear rule. Every test must guard a real risk, and the biggest risks get the most reliable tests.
Regression testing is where this pays off most. A regression test checks that what worked yesterday still works after a change. You run it again and again, so every extra test costs time on every run. The basics are in our guide to regression testing. Choosing what goes into the set is where risk helps.
How do you score the risk of each business flow?
Score each business flow from 1 to 3 on likelihood and on impact, and multiply the two. A business flow is something a user or system does from start to end, such as placing an order or approving an invoice. Scoring flows instead of single screens keeps the list short. Do the scoring with a developer, a tester and someone from the business in one room. Each of them sees risks the others miss. These questions help.
| Question | Scores high when | Example |
|---|---|---|
| Does it change often? | The code changes most sprints | Discount rules |
| Is the logic complex? | There are many rules and exceptions | Tax per country |
| Does it link to other systems? | Data goes in or out | Payment provider, ERP |
| Has it broken before? | It has a history of bugs | An export that failed twice this year |
| Does it touch money or the law? | Amounts, invoices or personal data | Refunds, privacy settings |
| How many people rely on it? | Customers or staff use it every day | Login, search, checkout |
A score of 6 or 9 means the flow belongs in the automated regression set. A score of 3 or 4 calls for a lighter check. A score of 1 or 2 may not need a regression test at all.
How do you pick a small regression set?
Start at the top of your risk list and work down until your critical flows are covered, then stop. For each high-risk flow, write one reliable test that follows the main path from start to end. Add tests for the edges that carry the most risk, such as a refused payment. Check business rules on the faster API layer where you can. Then set a time budget, for example that the whole set runs in under an hour. A budget forces choices, and those choices are the point. These steps work in most teams.
- List your flows. Aim for the things your business can’t do without, not every screen.
- Score them together. Use the questions above and agree on one number per flow.
- Cover the top. One end-to-end test per critical flow, plus its riskiest edges.
- Check your old tests. Tests that guard nothing on the list move to a weekly run or go.
- Review the list. Do it every quarter and after every incident in production.
At e-commerce clients we often see the opposite. There are hours of automated tests, and still critical incidents in production, because the flows that matter most were never covered end to end. What we help build instead is a compact suite with the most risk coverage in the least run time. The same thinking holds for critical systems. For the new operating software of the Maeslant storm barrier, our Delta Works case describes a risk-based test strategy based on TMap. That strategy kept changing with what testing found. Any regression set needs the same habit, because the risk list is never finished.
What do you leave out, and when is that a mistake?
Leave out tests that guard a low risk, repeat another test, or keep failing for reasons that have nothing to do with a real bug. Cutting tests feels risky, but a test that fails at random does more harm than good. People learn to ignore red results, and then they miss the real ones too. Our post on flaky tests explains why that happens. Our testers now see a new version of this problem. Some teams generate lots of tests with AI simply because it’s easy, without a plan for what each test should guard. The suite grows fast, and so does the number of tests that fail for no clear reason. DORA’s research on test automation makes the same point from another side: tests are only useful when a failure means a real problem.
Risk-based testing has limits too, and it’s fair to name them. A risk list is only as good as the people who made it, and people score what they know. A flow nobody thought of gets no test. So keep two safety nets. Exploratory testing by a person finds the problems no list predicted. Acceptance testing by business users checks that the software fits how they really work. A smarter regression set replaces neither. And for safety-critical systems, a small set is not the goal. There, risk decides how deeply you test, not whether you test.
What this means for your team
Picking the first set takes a morning. Keeping it right is the hard part. Every release adds flows and changes old ones, and each change can move a risk up or down. Someone has to update the list, adjust the tests and remove what no longer matters. In many teams that work belongs to nobody. So the suite slowly grows back to all night.
That ongoing work is what we do with Test Automation as a Service. Together with your team, we start with the business flows that carry the most risk, so the effort goes where it counts. Your tests run every night, and we keep them reliable. Your team decides what ships. One TaaS client described the start on our site. “Nekst IT is able to understand the business very fast, so they can think along on what to automate and what not”.
A first step you can take this week: write down your ten most important business flows. Score each one for likelihood and impact. Then check which of the top five your current tests really cover.
A small regression set that guards what matters, every night.
Frequently asked questions
What is the difference between risk-based testing and regression testing?
Regression testing checks that what worked still works after a change. Risk-based testing is a way to choose which tests to run, and how deeply. You use it to keep a regression set small and focused.
How many tests should a regression set have?
There is no right number. Start from your critical flows and set a time budget, such as one hour. If the set needs more time, move checks to faster layers or cut low-risk tests.
Who should do the risk scoring?
A small group: a developer, a tester and someone from the business. The developer knows what changes often. The business knows what hurts most. The tester brings the two together.
How often should you update the risk list?
Every quarter, and after every incident in production. Also update it before a big change, such as a new integration or a new platform.