- ✓Risk-based testing starts from the recognition that it is usually impossible to test everything in a complex system and that testing effort must therefore be prioritised based on which failures would be most likely and most harmful.
- ✓Risk in a software testing context has two components: the likelihood that a failure will occur and the impact of that failure if it does occur: both must be assessed to determine the overall risk level and appropriate testing priority.
- ✓Risk identification should involve the full project team, including business stakeholders who understand the impact of different types of failure, not just the testing team who understand the technical likelihood.
- ✓Risk-based testing is not about reducing the total amount of testing: it is about ensuring that the testing effort that is performed is focused where it will have the most impact on the quality and reliability of the delivered system.
- ✓Documenting the risk assessment that underpins a test strategy is essential for transparency and auditability: stakeholders and auditors need to be able to see that testing decisions were made systematically rather than arbitrarily.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Welcome back to HTQ Digital Technologies: The Study Podcast. I'm Alex, and today Sam and I are starting Unit 12 at Level 5, which is about risk analysis and systems testing. Sam, this might sound like a dry subject but it's absolutely central to producing reliable software.
Sam: It is, and it's an area that I think is genuinely undervalued in how software development is taught. Testing is often treated as something you do at the end, a quality gate before release. Risk-based testing is a fundamentally different philosophy: it's a strategic approach to quality that shapes decisions throughout the development process.
Alex: Let's start with the core concept: what is risk-based testing and how does it differ from conventional testing?
Sam: Conventional testing, in its purest theoretical form, would test every possible combination of inputs and system states to verify that a system behaves correctly in all cases. For any non-trivial software system, that's not just impractical, it's mathematically impossible. There are too many possible combinations. So some prioritisation is always necessary, and risk-based testing makes that prioritisation systematic rather than intuitive. It focuses testing effort on the areas where the combination of likelihood and impact of failure is highest.
Alex: How do you assess risk in a software testing context? What does that process look like?
Sam: Risk assessment starts with risk identification: what are the ways in which this system might fail? This requires input from multiple perspectives: the development team understands the technical complexity and where the hard problems are; the business understands which functions are most critical to operations; and end users understand the scenarios they most depend on and the consequences of failures in those scenarios. Once you have a list of potential failure modes, you assess each one on two dimensions: the likelihood of that failure occurring and the impact if it does. Combining these dimensions gives you an overall risk rating that drives prioritisation.
Alex: And then what do you do with that risk assessment?
Sam: You allocate testing effort proportionally to risk. High-risk areas get the most thorough testing, with multiple test techniques applied and significant time invested. Medium-risk areas get adequate but less intensive testing. Low-risk areas may be tested only lightly or covered by automated regression testing without extensive manual attention. This approach doesn't mean you ignore low-risk areas completely: it means you make rational decisions about where to invest limited testing time for maximum quality impact.
Alex: Is risk-based testing used in Agile environments as well as more traditional ones?
Sam: Very much so. In fact, it's arguably more important in Agile because the time pressure within a sprint means testing time is always constrained. Knowing explicitly which risks to prioritise means that even when time runs short and something has to give, the team is making an informed decision about what to leave less thoroughly tested, rather than just running out of time randomly. Risk assessment in Agile is typically less formal and more continuous than in traditional approaches, updated with each sprint's new functionality.
Alex: Really clear foundation. Thanks, Sam. We'll look at creating a risk-based test strategy next.