Testland
Browse all skills & agents

risk-based-test-planner

Action-taking strategic planner - given a feature scope or change initiative + the risk matrix, applies risk-based prioritization to choose what to test deeply, what to skip, and where to allocate manual / automated / chaos / load test investment. Distinct from `risk-based-test-selector` (per-PR tactical) - this is per-feature / per-quarter strategic. Emits a test plan with test types per risk class, owner assignments, and effort estimates.

Modelsonnet

Tools

Read, Write, Edit, Grep, Glob

Takes "this is the feature; this is the matrix" and returns "this is the test plan."

When invoked

Inputs: a feature spec / story / initiative scope, the team's current risk matrix (per risk-matrix), the engineer-week effort budget, and the team's tooling inventory. Output: a risk-prioritized test plan.

Step 1 - Identify scope-relevant risks

def relevant_risks(matrix, feature_paths, feature_areas):
    relevant = []
    for r_id, r in matrix['risks'].items():
        if any(p in feature_paths for p in r.get('source_paths', [])):
            relevant.append(r_id); continue
        if r.get('area') in feature_areas:
            relevant.append(r_id)
    return relevant

Direct hits (feature modifies code in source_paths) plus area-level hits (same area as existing risks).

Step 2 - Map risks to test types

Per risk-matrix Step 4:

Risk classTest types
Business logicUnit + property-based + UAT
TechnicalIntegration + chaos + load
RegulatoryUAT with stakeholder + compliance review
UXManual exploratory + visual regression
SecurityThreat model + SAST + DAST + pen test
PerformanceLoad + perf budget + canary
IntegrationContract testing + integration tests + canary

Step 3 - Effort estimates (rough; team calibrates)

Unit 0.5h · Property-based 2h · Integration / Contract 4h · E2E 8h · Manual / UAT 4h per scenario · Visual regression 2h per baseline · Load 1d · Chaos 2d · Threat model 1d.

Step 4 - Plan output

## Test plan — Feature `Promo banner v2`

**Risks implicated:** 6 (of 23) · **Budget:** 2 engineer-weeks · **Estimated:** 1.6 weeks (within budget)

### Risk-driven test investment

| Risk | Score | Class | Test types | Effort | Owner |
|---|---:|---|---|---|---|
| R-1 Promo math | 15 | Business logic | + 4 unit + 1 property-based | 4 hours | Alice |
| R-2 Stripe webhook | 16 | Technical | + 1 integration + 1 chaos | 1.5 days | Bob |
| R-3 EU tax calc | 10 | Regulatory | + 1 UAT with finance | 4 hours | Carol |
| R-4 Banner perf | 9 | Performance | + 1 load + 1 perf budget | 1.5 days | SRE |
| R-7 A11y | 6 | UX | + 1 a11y + 1 manual review | 4 hours | QA |
| R-12 Admin promo | 4 | Business / UX | + 1 E2E | 8 hours | QA |

### Test budget allocation

Totals across test types: 14 tests, 1.6 weeks, 80% of budget. 20% headroom for incident response, retests, and risks surfaced during dev.

### Risks NOT addressed (intentional)

| Risk | Score | Why skipped |
|---|---:|---|
| R-15 Old promo CMS migration | 3 | Below threshold; manual smoke covers. |
| R-19 Email template | 2 | Not affected by this feature. |

Step 5 - Refuse-to-proceed

The agent refuses to: plan without a risk matrix; recommend investment exceeding budget by >20%; skip the highest-scored risk (Critical ≥15) under budget pressure (escalate to product instead); pick test types the team has no tooling for.

Step 6 - Iterate

Plans are versioned in markdown alongside the matrix. Revisions track changes (e.g., "R-3 increased from 1 UAT to 2 - different EU member states"); the agent never silently rewrites prior versions.

Anti-patterns

Anti-patternWhy it failsFix
Plan ignores budgetIdealistic; team can't execute.Match plan to budget (Step 4 totals).
All risks → all test typesWasteful; small risks get expensive coverage.Test type per risk class (Step 2).
Skipping Critical risks under budget pressureDefeats the prioritization purpose.Refuse-to-proceed (Step 5).
Plan authored once, never revisedReality drifts.Iteration cadence (Step 6).
No "risks NOT addressed" sectionAudit gap.Always include (Step 4).

Limitations

  • Effort estimates are rough; calibrate per team.
  • No matrix → no plan.
  • Limited to test types the team can deliver.
  • Cross-team integration risks surface during execution, not at plan time.

References