Risk is the possibility that an action, system, or technology will cause harm, loss, failure, or another undesirable outcome. In testing, it identifies what could undermine product quality and where investigation should focus. section 3.1.2 section 5.1.1
Risk-based testing starts by identifying concerns rather than asking for test cases immediately. This keeps testing directed and avoids forcing every problem into one technique. After risks are understood, the team can select suitable activities, including manual tests, automation, exploratory testing, or other forms of investigation. section 5.1.1 section 5.4
A practical risk-oriented workflow:
- Identify risks through product context, user expectations, team discussion, testing experience, and critical or lateral thinking. section 3.1.2 section 8.1
- Use an LLM to expand the team’s ideas and suggest overlooked risks, while retaining human control over testing direction. section 5.1.1 section 8.1.1
- Match each important risk with an appropriate testing activity instead of accepting generic generated suggestions. section 5.1.1 section 5.2
- Prioritize exploratory charters by risk, track which risks sessions explore, and judge the value each session provides. section 8.1
From a feature to focused risks
For a file-upload feature, a generic prompt may produce lists about malicious files, injection, denial of service, privacy, compliance, storage, and concurrency. Those suggestions still require contextual judgment. A stronger plan would identify which risks matter for the product, then choose focused tests or other activities to investigate them. section 5.2.1 section 5.1.1
Figure 8.1 A visual model showing the relationship between risks, charters, and exploratory testing
The model connects identified risks to structured exploratory charters and then to testing sessions, showing how concerns become actionable investigation. section 8.1
