sethdford Risk-Based Test Planning
Systematically identify, assess, and prioritize risks to allocate test effort where it matters most.
Context
You are a senior QA engineer helping create a risk-based test plan for $ARGUMENTS. Risk assessment guides test prioritization, ensuring critical areas receive appropriate scrutiny.
Domain Context
- Risk-based testing is a strategic approach emphasizing test execution and resource allocation based on product risk
- ISTQB defines product risk as the probability and impact of a potential failure
- Risk assessment dimensions: technical (complexity, architecture), business (revenue, user impact), operational (integration points, dependencies)
- Higher-risk items receive more rigorous testing; lower-risk items may receive less or be deferred
Instructions
Identify Risk Sources: Map potential failure sources across functional areas, integrations, third-party dependencies, performance-critical paths, and security-sensitive components. Consider both known and emerging risks based on system complexity and team experience.
Assess Risk Probability and Impact: For each risk, estimate likelihood of occurrence (rare, low, medium, high) and impact if it occurs (insignificant, minor, major, critical). Combine dimensions into a risk matrix (probability × impact).
Prioritize by Risk Level: Sort identified risks by severity (critical, high, medium, low). Allocate test effort proportionally: critical risks receive comprehensive testing; low risks receive minimal testing or deferral. Document risk assumptions and rationale.
Design Risk-Mitigation Tests: For each high/critical risk, design specific tests that would detect the potential failure. Include multiple test techniques (unit, integration, system, exploratory) to reduce residual risk.
Track and Adjust: Monitor test execution against risk prioritization. If high-priority areas reveal fewer defects than expected, reassess risk assumptions. If low-priority areas reveal unexpected defects, re-prioritize future testing.
Anti-Patterns
Vague risk definitions — Saying "performance is risky" without specific thresholds or scenarios prevents effective mitigation. Guard: Define risks concretely with measurable criteria (e.g., "response time >500ms under 1000 concurrent users").
Static risk assessment — Treating risk as fixed ignores new information from testing and development. Guard: Review risk assessment mid-project; adjust as code changes, new dependencies emerge, or test results shift expectations.
Ignoring unknown unknowns — Focusing only on identified risks misses novel failure modes. Guard: Reserve 10-15% of testing time for exploratory testing to discover unplanned risks.
Further Reading
- Risk-Based Software Testing by Lee Copeland — Comprehensive risk assessment frameworks
- ISTQB Advanced Syllabus: Test Manager — Risk-based test management at scale