Risk-Based Testing
You will never have time to test everything. Test planning is the discipline of deciding what to test first, how deeply, and when to stop. Risk-based testing provides a structured framework for making these decisions, ensuring that your limited testing effort is concentrated where it will prevent the most damage.
The Risk Equation
Risk = Probability of failure x Impact of failure.
Every feature area in your application carries a different level of risk. A payment processing module that handles real money and has been recently modified carries far more risk than a static FAQ page that has not changed in six months.
Risk Assessment Matrix
| Feature Area | Likelihood of Defects | Business Impact | Risk Level | Test Depth |
|---|---|---|---|---|
| Payment processing | Medium | Critical | High | Full regression, edge cases, security |
| User profile editing | Low | Low | Low | Happy path, one negative case |
| New third-party integration | High | High | Critical | Exhaustive: positive, negative, timeout, auth failure |
| Static FAQ page | Very low | Very low | Minimal | Smoke test only |
| Search functionality | Medium | Medium | Medium | Core scenarios, performance spot check |
| Admin user management | Low | High | High | CRUD operations, permission boundaries, audit logging |
Factors That Increase Likelihood
- Recently modified code: New or changed code has more bugs than stable code
- Complex business logic: Multi-condition rules have more edge cases
- Third-party dependencies: External APIs, payment gateways, auth providers
- First-time implementation: The team has never built this type of feature before
- Technical debt: Areas with known code quality issues
- Concurrency: Features that handle parallel requests or shared state
Factors That Increase Impact
- Revenue-generating flows: Checkout, subscription, payment
- User data: Registration, profile management, data export
- Security boundaries: Authentication, authorization, data access controls
- Compliance features: GDPR deletion, audit logging, data retention
- Public-facing features: Anything visible to non-authenticated users
- Downstream dependencies: Features consumed by other services or partners
Applying Risk-Based Testing
Step 1: List Feature Areas
Work with the product owner and developers to list every feature area being released or modified.
Step 2: Assess Risk
For each area, rate likelihood (Very Low / Low / Medium / High) and impact (Very Low / Low / Medium / High / Critical). Use the matrix above to determine overall risk level.
Step 3: Assign Test Depth
| Risk Level | Test Depth |
|---|---|
| Critical | Exhaustive: all positive cases, all negative cases, edge cases, security, performance, cross-browser |
| High | Thorough: all positive cases, key negative cases, boundary values, one cross-browser check |
| Medium | Standard: happy path, key negative cases, one boundary check |
| Low | Light: happy path only |
| Minimal | Smoke: verify the feature loads and basic functionality works |
Step 4: Prioritize Execution
Test critical and high-risk areas first. If time runs out, you have already covered the most important scenarios.
Estimation Techniques
Accurate estimation of testing effort is a skill that improves with experience. Three techniques:
Work Breakdown Estimation
List every test type needed, estimate each:
| Test Type | Estimated Time |
|---|---|
| Functional positive cases (12 cases) | 3 hours |
| Functional negative cases (8 cases) | 2 hours |
| Edge cases and boundary values | 2 hours |
| Cross-browser testing (3 browsers) | 1.5 hours |
| Exploratory session | 1 hour |
| Bug verification and retesting | 1 hour |
| Total | 10.5 hours |
Historical Analogy
"The last feature of similar complexity took 3 days of testing." This works best when your team tracks testing time per feature.
Keep a log:
- Feature X (medium complexity, API + UI): 2.5 days
- Feature Y (high complexity, third-party integration): 5 days
- Feature Z (low complexity, UI-only change): 0.5 days
Three-Point Estimation
(Optimistic + 4 x Most Likely + Pessimistic) / 6
Example:
- Optimistic: 2 days (everything goes smoothly, no blockers)
- Most Likely: 3 days (typical amount of issues and retesting)
- Pessimistic: 6 days (major bugs found, environment issues, scope creep)
Estimate = (2 + 4(3) + 6) / 6 = 3.3 days
This accounts for uncertainty better than a single-point estimate.
Entry and Exit Criteria
Entry Criteria
Entry criteria define the conditions that must be met before testing begins. Starting to test before entry criteria are met leads to wasted effort on an unstable build.
Common entry criteria:
- Build deployed to test environment successfully
- Smoke tests passing (critical paths work)
- Test data loaded and verified
- Requirements/acceptance criteria document available and reviewed
- Test environment accessible and stable
- Known environment issues documented (so testers do not report them as bugs)
Exit Criteria
Exit criteria define when testing is "done enough" to proceed to release.
Common exit criteria:
- All critical and high-severity bugs resolved and verified
- 95% of planned test cases executed (remaining 5% justified)
- No open blockers
- Regression test suite passing (green)
- Exploratory testing sessions completed for high-risk areas
- Performance benchmarks met (response times within SLA)
When Exit Criteria Are Not Met
Sometimes the release deadline arrives before exit criteria are met. Document:
- Which criteria are not met
- The associated risks
- Your recommendation (release / do not release / release with mitigations)
This is a risk acceptance decision for management, not a QA decision. QA provides the data; management accepts the risk.
Test Plans
A test plan is the document that captures your risk-based testing strategy for a specific release or feature.
Lightweight Test Plan Template
Feature: Checkout Flow Redesign
Release: v2.5.0
QA Lead: Jane D.
Date: 2024-03-15
SCOPE:
- In scope: New checkout UI, payment integration, order confirmation
- Out of scope: User registration, product catalog, admin panel
RISK ASSESSMENT:
- Payment processing: CRITICAL — new integration with Stripe v3
- Address validation: HIGH — new autocomplete API
- Order confirmation: MEDIUM — mostly UI changes
- Email notifications: LOW — existing system, no changes
TEST APPROACH:
- Functional: 25 test cases covering all risk levels
- Exploratory: 2 sessions focused on payment edge cases
- Cross-browser: Chrome, Firefox, Safari (latest)
- Performance: Load test checkout with 100 concurrent users
ENTRY CRITERIA:
- Build deployed to staging
- Stripe sandbox configured
- Test accounts created (3 roles: admin, customer, guest)
EXIT CRITERIA:
- All critical/high bugs resolved
- 90%+ test case pass rate
- Payment flow verified for all card types
SCHEDULE:
- Day 1-2: Functional testing
- Day 3: Exploratory sessions
- Day 4: Cross-browser and regression
- Day 5: Bug verification and sign-off
Practical Exercise
You are the QA lead for a release that includes:
- A new payment method (Apple Pay integration)
- A redesigned user settings page
- A bug fix for a search indexing issue
- Updated Terms of Service page
Create a risk assessment matrix for these four items, assign test depth, estimate testing time using three-point estimation, and define entry/exit criteria.
Key Takeaways
- Risk = Probability x Impact. Test high-risk areas first and deepest.
- Use risk assessment to allocate limited testing time where it matters most
- Three estimation techniques: work breakdown, historical analogy, three-point
- Entry criteria prevent wasted testing on unstable builds
- Exit criteria define "done enough" — and what to do when they are not met
- Document your risk-based strategy in a lightweight test plan