No project has enough time to test everything with the same thoroughness. So the question is not whether to prioritise, but how: by gut feeling and habit – or transparently, by risk. Risk-based testing ensures that scarce testing time is spent where a defect would cause the most damage. This article explains how the method works and how to bring it into your project in four steps.
Risk-based testing is an approach in which the scope, depth and order of testing are determined by risk. A risk results from two factors: the likelihood of a defect and its impact if it occurs in production. Functions with a high risk are tested earlier, more intensively and with stronger test techniques; functions with a low risk receive less effort.
The approach is not a niche idea but an established part of testing fundamentals: the ISTQB syllabus describes risk-based testing as a central strategy, and the ISO/IEC/IEEE 29119 series of standards also puts risk at the heart of test planning. In practice, however, it is often only half implemented – there is a risk list in the test plan, but it has no influence on what is actually tested.
For testing, product risks matter most: the danger that the software does not do what it should in production. Examples are incorrect calculations, data loss, security vulnerabilities, poor response times under load or a user interface that users do not understand.
Project risks, by contrast, concern execution: late deliveries, missing test environments, limited staff capacity or unclear requirements. They do not determine what is tested, but they do determine whether the planned testing can take place at all. How to manage such risks in a project is described in our article Risk Management in IT Projects.
The starting point is a collection of possible product risks. It is best created together: business, development, operations and testing each see different dangers. Proven sources are requirements and business processes, the defect history and incident reports of previous releases, architecture and interfaces, and legal or contractual requirements. A short workshop with focused questions – "What must never go wrong?", "Where did we have problems last time?" – usually produces a usable list quickly.
Each risk is rated by likelihood and impact, for example on a simple scale from low through medium to high. Likelihood is mainly estimated by the technical team: How complex is the code, how new is the technology, how many changes were made, how error-prone has the area been so far? Impact is mainly assessed by the business: How many users are affected, are there financial or legal consequences, does customer trust suffer?
Plotting both values in a risk matrix makes the priorities visible. It is important that the assessment is shared by several people. A matrix filled in by one person alone reflects their point of view rather than the actual risk.
Only in this step does the assessment turn into a test strategy. Risk influences several levers:
A risk assessment is a snapshot. During the project, requirements change, new clusters of defects appear, and some feared problems turn out to be harmless. That is why the risk list should be reviewed regularly – at fixed milestones in traditional projects, in Scrum for example during refinement or before a release. Defect statistics from ongoing testing are a valuable indicator: where defects accumulate, the likelihood is evidently higher than assumed.
The greatest benefit often shows at the end. Instead of "82 of 100 test cases passed", the test team reports which risks are sufficiently covered and which are not. Project management and the business can use this statement directly for their release decision: they see which residual risk they accept with a go-live. A release with open defects in a peripheral function can be acceptable; an untested core process usually is not.
For this to work, the exit criteria in the test plan should also be risk-based, for example: all test cases for high risks have been executed, and there are no open defects of the highest severity class in those areas.
Risk-based testing makes sense in Scrum too, just at a smaller cadence. During refinement, the team can briefly ask for each user story what could go wrong and how bad that would be. The result feeds into the acceptance criteria, the estimate and the Definition of Done. For the product as a whole, a lean, jointly maintained risk list that is reviewed before releases remains useful. How testing fits into the sprint overall is described in our article Agile Testing in Scrum Teams.
Risk-based testing makes test priorities transparent: identify risks together, rate them by likelihood and impact, derive test depth and order from that, and keep the assessment up to date. The result is not additional bureaucracy but a better basis for every decision in testing – right up to the release. Why structured quality assurance decides project success overall is explained in Why Quality Assurance Decides Project Success.
Risk management looks at all risks of a project, such as deadlines, budget or staffing. Risk-based testing focuses on product risks, i.e. possible defects in the software, and uses their assessment to determine the scope, depth and order of testing. The two complement each other: project risks influence whether the planned testing can take place.
Ideally a mixed team. The business or Product Owner estimates the impact, development and architecture the likelihood. Test management facilitates the assessment and derives the test approach from it.
Yes. Even a short list of the most important risks with a simple high, medium and low rating helps to distribute the available testing time sensibly. In small projects, the effort is often a single short workshop.
30-minute initial consultation — free and without obligation. Together we look at your project and show where risk-based testing makes your testing time more effective.
Book a Free Initial ConsultationMore about our service: Software Quality Assurance in Hamburg →
Related: IT Project Management in Hamburg →