- ✓A test strategy is a high-level document that defines the overall approach to testing for a project or system, including the scope of testing, the types of testing to be performed, the tools to be used and the criteria for success.
- ✓Risk-based test strategies explicitly link testing activities to identified risks, showing how each significant risk will be addressed through specific testing approaches and how coverage will be measured.
- ✓Entry and exit criteria define when testing activities should start and when they can be considered complete: without these criteria, it is impossible to make objective decisions about readiness and quality.
- ✓Test technique selection in a risk-based approach should match the nature of the risk: equivalence partitioning and boundary value analysis work well for testing known input ranges, while exploratory testing is better suited to detecting unexpected and creative failure modes.
- ✓A well-written test strategy communicates a clear and justified approach to a diverse audience that includes technical testers, project managers and senior business stakeholders: clarity and traceability are as important as technical sophistication.
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: Hello and welcome back. Today we're looking at how to create a risk-based test strategy. Sam, this is the document that sets the direction for all the testing on a project, isn't it?
Sam: It is. The test strategy is the highest-level testing document for a project or system. It defines the overall approach: what will be tested, how it will be tested, who will test it and what success looks like. The risk-based version of this document explicitly connects every decision about testing scope and approach to the risk assessment.
Alex: What are the key components of a well-structured test strategy?
Sam: I'd say there are eight key components. First, the scope and objectives: what is being tested and what are the goals of the testing activity? Second, the risk assessment: a documented analysis of the risks being addressed, showing how likelihood and impact were assessed. Third, test approach: the overall philosophy and the mix of testing types to be used. Fourth, test techniques: the specific methods to be used for different types of test, such as equivalence partitioning, boundary value analysis and exploratory testing. Fifth, entry and exit criteria: the conditions that must be met before testing can start and before it can be considered complete. Sixth, resource requirements: who, what tools and how much time. Seventh, schedule: when will testing activities happen in relation to development. And eighth, risk management: what risks to the testing process itself have been identified and how will they be managed.
Alex: The entry and exit criteria seem particularly important for managing expectations.
Sam: They're critical for preventing two common problems. Without clear entry criteria, testing is sometimes started before the software is in a state that makes testing meaningful, which wastes effort. Without clear exit criteria, testing can go on indefinitely with no objective basis for deciding when enough is enough, or conversely, testing can be arbitrarily cut short when time pressure mounts. Well-defined criteria make these decisions explicit and objective rather than subjective and political.
Alex: How do you choose the right test techniques for a given risk?
Sam: The nature of the risk determines the appropriate technique. Equivalence partitioning divides the input space into groups that the system should treat equivalently, and tests one representative from each group: this is efficient and works well for risks around input validation. Boundary value analysis focuses on the values at the edges of valid ranges, which is where many bugs cluster. Decision table testing maps out complex combinations of conditions and expected outcomes systematically. Exploratory testing, where testers freely investigate the system using their expertise and intuition, is particularly good for finding unexpected failure modes that specification-based techniques might miss.
Alex: What does a risk-based test strategy look like in a real assessment context?
Sam: It should demonstrate that you understand both the system you're testing and the testing discipline. It should show a credible risk assessment, not just a generic list of risks but ones specific to the system in question. The testing approach should be clearly connected to the risks, showing why specific techniques are appropriate for specific risks. And the whole document should be written clearly enough that someone unfamiliar with the project could understand what's being tested and why.
Alex: Really practical and assessment-ready. Thanks, Sam. We'll look at building and executing a test plan next.