Risk-Based Testing: Focusing on What Matters Most | Amber Insights #005
Updated: Sep 8
By Amber Idumwonyi
One of the most important lessons I have learned in Quality Engineering is that not everything can or should be tested with the same level of intensity.
Software systems can contain hundreds of features, integrations, business rules, user journeys, and technical components. Delivery teams, however, operate within real constraints: time, budget, environments, data, people, and release deadlines.
This creates an important question for every Quality Engineer:
Where should we focus our testing effort?
The answer should not simply be, "test everything."
It should be:
Test according to risk.
Risk-based testing helps teams concentrate their effort where failure could cause the greatest harm. It moves testing away from treating every requirement equally and towards making deliberate, evidence-based decisions about what matters most.
What Is Risk-Based Testing?
Risk-based testing is an approach in which testing priorities are influenced by the likelihood of something going wrong and the impact if it does.
A simple way of thinking about it is:
Risk = Likelihood × Impact
Likelihood considers how probable a failure may be.
Impact considers the consequences if that failure occurs.
Those consequences could affect:
Customers or service users
Financial transactions
Sensitive information
Regulatory obligations
Business operations
Organisational reputation
Critical integrations
Accessibility
Service availability
A feature with a high likelihood of failure but very little impact may require a different level of testing from a feature where failure is unlikely but the consequences could be severe.
Risk-based testing helps us recognise that distinction.
Not All Functionality Carries Equal Risk
Imagine an online banking application.
The system contains functionality allowing a customer to:
Change their profile picture.
Update their communication preferences.
View their account balance.
Transfer money.
Add a new beneficiary.
Reset their password.
All these features matter.
But they do not carry the same risk.
If a customer's profile picture fails to update, the experience may be frustrating, but the consequences are relatively limited.
If the same customer transfers £1,000 and the money is deducted twice, sent to the wrong account, or recorded incorrectly, the consequences are significantly greater.
Should both features receive exactly the same testing effort?
Probably not.
This is where risk-based testing becomes practical.
The payment journey would likely require deeper validation across business rules, integrations, security, data integrity, error handling, recovery scenarios, and potentially performance.
The profile-picture functionality still needs appropriate testing, but the depth and priority can reflect its comparatively lower business impact.
Equal test coverage does not necessarily mean effective test coverage.
Identifying Risk Starts with Understanding the Business
A Quality Engineer cannot assess risk effectively without understanding what the software is intended to achieve.
This is why domain knowledge matters.
Before deciding what deserves the greatest testing attention, we need to understand questions such as:
What functionality is critical to the organisation?
Which journeys are used most frequently?
Which processes involve money or sensitive information?
Which features support regulatory or legal obligations?
Which components depend on external systems?
Where has the system historically experienced problems?
Which failures would prevent users from completing essential tasks?
These are not purely technical questions.
They require conversations with Product Owners, Business Analysts, Developers, Architects, operational teams, security specialists, and business stakeholders.
Quality Engineering therefore involves understanding both technical risk and business risk.
Assessing Likelihood
Likelihood is not guesswork.
There are indicators that can help a team determine where failures may be more probable.
For example, risk may increase when:
Functionality is technically complex.
Significant code changes have been introduced.
Multiple systems or APIs must communicate.
Requirements are unclear or frequently changing.
A component has historically produced defects.
New technology is being introduced.
There are numerous business rules or calculations.
Dependencies are outside the team's direct control.
The implementation has had limited development or testing time.
None of these automatically means that something will fail.
They tell us where uncertainty may be greater.
And uncertainty deserves attention.
Assessing Impact
The second dimension is impact.
If this functionality fails, what happens?
Impact can range from a minor inconvenience to a serious operational or customer problem.
Consider a digital public service.
A cosmetic alignment issue on an informational page may have relatively limited impact.
A defect that prevents an eligible person from submitting an essential application could have a much more significant consequence.
Similarly, a defect exposing another user's personal information could carry serious privacy and security implications.
Impact therefore needs to be considered from several perspectives:
User impact: Can users still complete their objective?
Business impact: Could the failure affect revenue, operations, or service delivery?
Security impact: Could information or systems be compromised?
Regulatory impact: Could the organisation breach legal or regulatory obligations?
Reputational impact: Could the failure reduce public or customer trust?
Understanding impact changes the way we prioritise testing.
Creating a Simple Risk Matrix
Risk assessment does not always require a complicated framework.
A simple matrix can be extremely effective.
Teams might classify likelihood as:
Low
Medium
High
And impact as:
Low
Medium
High
The combination determines the overall priority.
For example:
Likelihood | Impact | Indicative Risk |
High | High | Critical |
Medium | High | High |
High | Medium | High |
Medium | Medium | Medium |
Low | High | Medium/High depending on context |
Low | Low | Low |
The important point is not the label itself.
The value comes from the conversation behind the classification.
Why do we believe this functionality is high risk?
What evidence supports that assessment?
What testing will reduce the uncertainty?
What level of residual risk is the organisation prepared to accept?
Those conversations create much greater value than simply colouring cells red, amber, and green.
Risk Should Influence Test Coverage
Once risks have been identified, they should influence the test approach.
Higher-risk functionality may justify:
More detailed test scenarios.
Greater negative testing.
Boundary and edge-case analysis.
Integration testing.
Security or accessibility testing where relevant.
More extensive regression coverage.
Exploratory testing.
Additional test data combinations.
Greater automation coverage where appropriate.
Closer monitoring after release.
Lower-risk functionality may require a lighter approach.
This does not mean ignoring low-risk areas.
It means allocating effort proportionately.
A mature testing approach does not ask:
"Did we test everything?"
It asks:
"Did we test the things that matter to the depth their risk requires?"
Risk Changes Throughout Delivery
Another important principle is that risk assessment should not happen once and then disappear into a document.
Risk changes.
A feature initially considered straightforward may become more complicated during implementation.
A new dependency may be introduced.
Requirements may change.
A defect may reveal a wider architectural issue.
An external service may become unstable.
Production behaviour may expose risks that were not apparent during development.
Risk-based testing therefore needs to remain dynamic.
Quality Engineers should continually reassess priorities as new information becomes available.
That adaptability is particularly important in complex delivery environments where circumstances can change quickly.
What Happens When Time Runs Out?
This is where risk-based testing becomes especially valuable.
Almost every experienced tester has encountered a situation where a release deadline remains fixed but the available testing time becomes shorter.
Development finishes later than expected.
An environment becomes unavailable.
A dependency fails.
A critical defect requires retesting.
Suddenly, five days of planned testing becomes two.
The wrong response is to randomly remove test cases until the remaining work fits the available time.
The better question is:
What must we test to understand the most significant remaining risks before release?
Critical business journeys should receive priority.
High-impact integrations should receive attention.
Areas affected by recent changes should be evaluated.
Previously problematic functionality may require regression.
Lower-risk scenarios may be deferred if necessary, but that decision should be visible and understood.
Risk-based testing does not remove the consequences of limited time.
It helps teams make better decisions within those constraints.
Risk-Based Testing Does Not Eliminate Risk
No amount of testing can prove that complex software contains no defects.
Testing provides information.
It reduces uncertainty.
It identifies problems.
It increases confidence.
But some level of risk will always remain.
This is known as residual risk.
One of the responsibilities of Quality Engineering is therefore not simply to say:
"Testing is complete."
It is to communicate:
What has been tested.
What has not been tested.
What significant defects remain.
What limitations affected testing.
What risks are still present.
What those risks could mean for the business.
The final decision to release may belong to the appropriate business or delivery authority.
Our responsibility as Quality Engineers is to ensure that decision is informed by clear, credible evidence.
Risk-Based Testing Is Ultimately About Decision-Making
Risk-based testing is sometimes presented as a testing technique.
I see it as something broader.
It is a decision-making discipline.
It helps teams decide where to invest effort.
It helps testers determine the depth of coverage required.
It helps stakeholders understand trade-offs.
And when circumstances change, it provides a rational basis for deciding what matters most.
That is especially important because software delivery will always involve constraints.
We will rarely have unlimited time.
We will rarely have unlimited people.
We will rarely have perfect environments.
And we will never be able to test every possible combination of behaviour.
What we can do is make intelligent decisions about where quality matters most.
Final Thoughts
Good testing is not measured by how many test cases we execute.
It is measured by how effectively our testing helps the organisation understand and manage quality risk.
That requires us to look beyond requirements and ask deeper questions.
What could go wrong?
How likely is it?
What would happen if it did?
How much confidence do we need before releasing it?
When those questions guide our testing decisions, testing becomes more focused, more defensible, and more valuable to the organisation.
Because effective Quality Engineering is not about testing everything equally.
It is about understanding what matters most and making sure our testing reflects it.
About the Author
Amber Idumwonyi is a Senior Quality Engineering Leader with over eight years of experience delivering quality engineering solutions across UK Government, defence, healthcare, and enterprise technology programmes. She has led Quality Engineering initiatives, developed enterprise Test Strategies, contributed to modern testing and automation practices, spoken at industry conferences, and founded LEMP, an organisation focused on practical technology education, mentoring, industry experience, and career development.
Amber is passionate about Quality Engineering, AI-assisted testing, technical leadership, and developing the next generation of technology professionals.
Read More:
Amber Insights | Issue 001 – Why Every Successful Software Project Starts with a Test Strategy
Amber Insights | Issue 002 – Testing Is Not a Phase; It Is a Mindset
Amber Insights | Issue 003 – Understanding Software Quality Beyond Finding Bugs
Amber Insights | Issue 004 – The Evolution from Quality Assurance to Quality Engineering
Explore LEMP's Software Testing programme and learn how you can get started.
Comments