/qa-manual-istqb

Risk-Based Testing (ISTQB Foundation Level)

Part of the qa-manual-istqb skill. See SKILL.md for full context.

Risk-based testing (RBT) prioritizes test effort based on the likelihood and impact of failures. It ensures the most important areas receive the most attention, optimizing limited testing resources.

What Is Risk in Testing?

Risk = Likelihood × Impact

Types of Risk

Product Risks (Quality Risks)

Risks related to the software product itself:

Project Risks

Risks affecting the testing process:

Risk-Based Testing Process

Step 1: Risk Identification

Sources of risk information:

• Requirements and specifications
• Architecture and design documents
• Previous defect data
• Production incident history
• Stakeholder interviews
• Expert judgment
• Complexity analysis

Questions to ask:

• What could go wrong?
• What are the critical user journeys?
• What has failed before?
• What is complex or new?
• What integrates with external systems?
• What has regulatory/compliance implications?
• What would cause the most business damage?

Step 2: Risk Assessment

Rate each risk on likelihood and impact.

Likelihood factors:

• Complexity of the feature
• Technology newness
• Developer experience
• Frequency of changes
• Historical defect rate
• Quality of requirements

Impact factors:

• Number of users affected
• Business criticality
• Revenue impact
• Safety implications
• Regulatory consequences
• Reputational damage

Risk assessment matrix:

Step 3: Risk Prioritization

Order risks by risk level, then by:

• Business priority
• Dependencies
• Time sensitivity
• Stakeholder input

Prioritized risk list template:

Step 4: Risk Mitigation through Testing

Map risks to test activities:

Risk-to-test traceability:

Step 5: Risk Monitoring

Continuously update risk assessment:

• New risks identified → add to register
• Defects found → indicates likelihood was correct
• Risk mitigated → reduce priority
• Scope changes → reassess risks

Risk Assessment Template

# Risk Assessment - [Project/Feature]

## Risk Register

| ID  | Risk Description | Category | Likelihood (1-5) | Impact (1-5) | Risk Score | Priority | Mitigation |
| --- | ---------------- | -------- | :--------------: | :----------: | :--------: | :------: | ---------- |
| R1  |                  |          |                  |              |            |          |            |
| R2  |                  |          |                  |              |            |          |            |

## Risk Scoring Guide

### Likelihood

- 1: Very unlikely (rare, <10%)
- 2: Unlikely (occasional, 10-25%)
- 3: Possible (moderate, 25-50%)
- 4: Likely (frequent, 50-75%)
- 5: Very likely (almost certain, >75%)

### Impact

- 1: Trivial (cosmetic, workaround exists)
- 2: Minor (limited users, easy workaround)
- 3: Moderate (many users affected, workaround difficult)
- 4: Major (critical flow blocked, significant revenue impact)
- 5: Critical (system down, data loss, safety/legal implications)

### Risk Score

- Risk Score = Likelihood × Impact
- 1-5: Low | 6-12: Medium | 13-19: High | 20-25: Critical

Applying RBT to Test Planning

Test Case Prioritization

Order test execution by risk:

1. Critical risk areas first
2. High risk areas second
3. Medium risk areas third
4. Low risk areas last (or skip under time pressure)

Test Suite Tiers

Time-Constrained Testing

When time is limited:

1. Run all critical risk tests
2. Run high risk tests
3. Sample medium risk tests
4. Skip or defer low risk tests
5. Document what was not tested and residual risk

Risk-Based Test Reporting

Include in test summary:

Residual risk statement:

• Untested areas: [list]
• Known open defects: [list with impact]
• Risks accepted: [list with justification]
• Recommendations: [actions for remaining risk]

Benefits of Risk-Based Testing

Common Pitfalls