Table Of Contents
In Part 1, we covered why risk-based testing matters and what it actually means. Now comes the practical bit: how to do it without overcomplicating things or letting it become another process that quietly dies after a couple of sprints. We have all seen that happen.
The goal is simple. By the end of each sprint or release, you should be able to answer three questions: What are the top risks right now? What tests prove those risks are mitigated enough to ship? And what risk are we consciously accepting because we didn’t test it?
If you can answer those confidently, you’re doing risk-based testing. If you can’t, you’re guessing.
Templates referenced throughout this article are available at the bottom of the page.
Start with What You Know
Before you assess risk, you need to understand your product, your users, and your business priorities. That sounds obvious, but for some, not so much. I have worked with QA teams who’d been operating for months without a clear picture of any of them.
Your product is not just a feature list. It’s the architecture, the dependencies, the integrations, the spots where technical debt has piled up. It’s knowing which parts of the codebase are solid and which were rushed out the door at the last minute. If you don’t have this knowledge, go and get it. Sit with developers. Not a formal meeting, just a coffee and a chat. Read the incident postmortems. Look at where bugs have clustered historically. That history tells you more than most planning documents will.
Your users are not a monolith. Some features serve power users who will find creative ways to break things you didn’t think were breakable. Some serve casual users who follow the happy path and never touch the settings page. Understanding who uses what, and how aggressively, changes your risk calculations.
Then there’s business priorities. Is the company focused on growth? Stability? Compliance? Entering a new market? The answer changes which failures are tolerable and which are career-ending. A startup chasing product-market fit will accept more risk in edge cases than a financial services company with APRA breathing down its neck.
If you don’t have clarity on these three areas, that is your first task. Everything else builds on it.
Identifying Risks: Inside-Out
There are two ways to approach risk identification that work well together. The first starts with the product and asks: what can go wrong here?
For each component or feature, work through three questions:
What vulnerabilities exist? These are the weaknesses, the fragile bits, the things that have dependencies that could fail.
What threats could trigger those vulnerabilities? Think edge cases, unexpected user behaviour, integration failures, load spikes, bad data.
Who or what gets hurt if it fails? This is the impact side. Minor inconvenience, or regulatory breach?
I usually do this as a whiteboard session with the dev lead and product owner. Takes about an hour for a focused product area. You don’t need to be exhaustive, bullet points do the job. You just need to be honest about where things are weak.
Working through these questions systematically surfaces risks you’d otherwise miss. It forces you past “does this feature work” and into “what happens when it doesn’t.” That’s a different conversation, and a more useful one.
Identifying Risks: Outside-In
The second approach starts with known risk categories and maps them to your product. This catches things inside-out misses because you’re not just staring at your own codebase. You’re applying a checklist of common problem areas that trip up most teams.
New or changed code. What was recently modified? Fresh code hasn’t been battle-tested. This is statistically where bugs live.
Complexity. Which areas have tangled logic, nested conditions, or workflows that make your head hurt reading them? Complexity breeds defects.
Integration points. Where does your system talk to other systems? APIs, databases, third-party services. These fail in interesting ways, especially when the third party pushes a change without telling you.
High visibility. What do executives, key customers, or the market pay attention to? A bug here causes damage way beyond the technical impact.
High frequency. What do users do most often? Failures here affect the most people.
Critical path. What absolutely must work for the business to function? Checkout, login, core transactions. If these break, nothing else matters.
Past problems. Where have bugs clustered before? History is your best predictor. If a module has been problematic, assume it still is until proven otherwise.
Security and compliance. What handles sensitive data, authentication, or regulatory requirements? Failures here have legal consequences.
Performance. What might slow down under load? Performance issues love hiding until production.
Run through this list for your product. I keep a copy of these categories in Confluence and pull them out at every risk workshop. You will find things the inside-out approach missed.
Scoring and Prioritisation
Once you’ve identified risks, score them so you can prioritise. Keep this simple or you won’t maintain it. Unfortunately I’m serious. I have seen teams build elaborate 5×5 matrices with weighted subcategories and then abandon the whole thing after a few sprints because it all took too long.
Use a 1 to 3 scale for both likelihood and impact. For likelihood: 1 is unlikely to fail, 2 is moderately likely, 3 is very likely. For impact: 1 is minor inconvenience, 2 is significant, 3 is severe business impact. Multiply them and you’re done.
A score of 9 is critical. A score of 1 is low priority. Everything else falls somewhere in between.
Some teams prefer a 1 to 5 scale for more granularity. That’s fine if your organisation already thinks in those terms. But for most teams, 1 to 3 is enough. If scoring takes more than a few minutes per item, you’re thinking too hard, simplify.
The templates I’ve created for this series include a risk register spreadsheet with this scoring built in, conditional formatting and all. Grab it below if you want a starting point rather than building from scratch.
Converting Scores to Tiers
Raw scores are useful. Tiers are actionable.
Tier 1 (scores 6 to 9): test deeply. Negative cases, boundaries, edge conditions, integration scenarios, exploratory testing targeted at risk areas. You are trying to find the issues before users do. This is where QA earns its keep.
Tier 2 (scores 3 to 4): standard testing. Happy path plus key boundaries plus basic integration checks. You’re confirming it works as expected without going too deep.
Tier 3 (scores 1 to 2): baseline only. Does it load? Does the basic function work? You’re catching catastrophic failures, not subtle bugs.
Forcing items into tiers is the point. It makes you commit to trade-offs. If everything ends up in Tier 1, you haven’t done the hard work of prioritising. You’ve just relabelled “test everything.”
I’ve included a test depth policy template below that defines what each tier means in practice. One page. When a new tester joins, they can read it in five minutes and know exactly what “Tier 1 testing” looks like for your team.
The Minimum Baseline: Your Safety Net
One of the known downsides of risk-based testing is that low-risk areas can still produce embarrassing defects. Your checkout flow works perfectly, but the marketing team’s landing page throws a 500 error on launch day. It’s happened and it is not a fun conversation to be having.
Define a minimum baseline that always runs. Always. Make it the first thing, even under time pressure. Even when the release is running hot and someone wants to skip testing entirely, you have your safety net.
It typically includes a smoke test for build stability, login and basic navigation, and one happy-path scenario per major area. Keep it small, maybe 30 minutes to execute. Keep it stable and non-negotiable. Makes a great automation candidate, feeding the CI/CD pipeline.
The baseline catches the obvious breakages in areas you’ve deprioritised. It’s the difference between “we accepted the risk and nothing happened” versus “we accepted the risk and something embarrassing happened that a two-minute check would have caught.”
Mapping Risks to Tests
For each Tier 1 risk, you need traceability. Map the risk to the tests that mitigate it and to the results from those tests.
This doesn’t need to be elaborate. A column in your risk register that links risk items to test case IDs is enough. The point is that when someone asks “how do we know this risk is covered,” you can show them. It’s not knowledge locked in someone’s head, and it doesn’t walk out the door when someone moves on.
This traceability also helps when risks change. If something that was low risk suddenly gets promoted to “oh no, this is on fire,” you can see straight away what testing exists and where the gaps are.
The risk register template includes a traceability tab for this.
Execution Order
Most teams run regression tests in whatever order they were created. That’s an anti-pattern. If you run out of time, which you will, you’ve potentially skipped the most important tests while running low-value ones that happened to be first in the queue.
Reorder based on risk. Baseline first, for a fast “is it alive” confirmation. Tier 1 next, to protect the business. Then Tier 2. Tier 3 only if capacity remains.
If testing gets cut short, you’ve covered what matters most. That’s an informed trade-off, not an accident.
Keeping It Current
Risk-based testing fails when the risk model goes stale. A risk assessment from six months ago doesn’t reflect today’s product. New features shipped, code was refactored, production incidents revealed things nobody anticipated. The model has to move with the product.
Add a recurring review to your sprint cadence. Fifteen minutes is plenty. Review what changed this sprint, look at recent defects and production incidents, adjust the top risks. Don’t re-score everything, just focus on what changed. If nobody has anything to update, it’s a two-minute meeting.
I’ve included a sprint risk review agenda template that structures this fifteen-minute review. It keeps the meeting focused and prevents it from turning into a planning session or a retrospective.
The risk register is a living document. The moment you file it away and forget about it, you’re back to guessing. This is why I use Confluence, everyone can see it.
What’s Next
You now have the mechanics: how to identify risks, score them, tier them, map tests, define a baseline, and keep it all current. But they only get you so far.
The hardest part of risk-based testing is not the process. It’s getting buy-in from stakeholders who don’t understand why certain things aren’t being tested, handling the objections, and maintaining discipline when someone senior decides everything is suddenly critical and everything needs testing.
Part 3 covers exactly that. The human side.
The Take
Risk identification uses two approaches that work well together. Inside-out starts with your product and asks what can go wrong. Outside-in applies known risk categories like new code, complexity, integrations, and past problems to catch what you’d otherwise miss.
Scoring should be simple. 1 to 3 for likelihood and impact, multiplied. If it takes more than a few minutes per item, you’re overthinking.
Convert scores to three tiers with explicit test depth rules. Tier 1 gets deep testing, Tier 2 gets standard coverage, Tier 3 gets smoke checks. Define a minimum baseline that always runs so low-risk areas don’t produce embarrassing defects.
Map risks to tests for traceability. Reorder execution so high-risk items run first. Review every sprint so the model stays current. Fifteen minutes should be all.
The mechanics aren’t complicated. The discipline to maintain them is what separates teams that do risk-based testing from teams that talk about it.
Part 3 tackles buy-in, objections, and making it stick. That’s where it gets interesting.
Downloads
- intake-triage-checklist
- release-risk-report
- risk-register-toolkit
- sprint-risk-review-agenda
- test-depth-policy
A Note on Context
Every business and every project is different. What works in one place won’t work in another, and that’s the point.
Nothing here is meant to be a step-by-step prescription. It’s guidance, drawn from my own experiences, and deliberately kept general to avoid pointing fingers anywhere.
Take what’s useful, ignore what isn’t, and adapt it to your own context. Or as Joe Colantonio always says: “Test everything and keep the good.”
