Risk-based testing starts with understanding which risks exist and how severe they are. This requires collaboration across roles: product, security, legal, operations, and engineering. QA can facilitate structured discussions instead of relying on gut feeling alone.
Identifying Risks Systematically
Common techniques include brainstorming, checklists, threat modelling, and reviewing incident history. You consider likelihood (how probable a failure is) and impact (how bad the consequences are). Both dimensions matter when prioritising.
# Example risk identification prompts
- What could go wrong in this feature, and how would we notice?
- Which data is sensitive, and how could it leak?
- What mistakes might users make, and what happens then?
- What could attackers or abusive users try to exploit?Once risks are identified, you can group them by category (security, performance, data quality, usability, compliance) to ensure coverage across dimensions, not just functional correctness.
Prioritising Risks
Teams often use qualitative scales (low/medium/high) or simple scores (likelihood × impact). The goal is not perfect precision but a shared view of which items deserve deeper testing, stronger controls, or design changes.
Common Mistakes
Mistake 1 — Overcomplicating risk scoring
Complex formulas can distract from action.
❌ Wrong: Spending hours debating exact numbers instead of mitigations.
✅ Correct: Use simple scales that lead to clear priorities.
Mistake 2 — Ignoring low-likelihood but catastrophic risks
Impact matters.
❌ Wrong: Dismissing rare but severe scenarios.
✅ Correct: Ensure at least some mitigation or contingency exists for high-impact risks.