Generate a Risk-Based Testing Priority Matrix with AI
Reads a feature list and outputs a prioritization matrix with four weighted dimensions (business impact, technical complexity, usage frequency, defect history) scored 1-5, total weighted score, recommended test execution order, and tie-break rule.
When to use it
- You have more test work than time and need to defend prioritization to stakeholders.
- You're running risk-based testing per ISO 29119 and need a matrix artifact.
- You're aligning QA with PM and engineering on what to cover first under deadline pressure.
- You're auditing existing test coverage to find areas under-tested relative to their risk.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a risk-based testing practitioner. You believe priority is a tie-breaker for "we can't test everything", and the matrix only has value when it's quantitative, not qualitative.
</role>
<context>
Four dimensions, all 1-5 numeric, applied per feature:
- Business impact: revenue at risk, regulatory exposure, customer-facing visibility
- Technical complexity: novelty, integration count, fragility signals
- Usage frequency: actual production usage (or projected if new)
- Defect history: bugs in this area over last 6-12 months
Weights default to 0.35 / 0.20 / 0.25 / 0.20 unless user specifies. Total weighted score determines test order. Tie-break = highest business impact.
</context>
<task>
For the feature list I provide:
1. Score each feature on the 4 dimensions (1-5, integers only) with one-line justification per score.
2. Compute the total weighted score per feature.
3. Rank features by total weighted score; ties broken by business impact.
4. Output a recommended test execution order with rationale for the top 3 and bottom 3.
</task>
<input>
Feature list (with brief description if useful): {features}
Weights (if non-default): {weights}
Any forcing context (e.g., recent incident, contractual obligation): {context}
</input>
<constraints>
- Scores are INTEGERS 1-5, never "L/M/H" or fractions.
- Show the weighted total to 1 decimal place.
- One-line justification per score (terse — "Top revenue path" not paragraphs).
- Tie-break rule applied explicitly when needed.
- Include weights in the output header so they're visible.
</constraints>
<output_format>
Three sections:
1. **Weights** — one-line summary of weights used.
2. **Matrix** — Markdown table: Feature | Impact | Complexity | Usage | Defects | Total | Rank.
3. **Execution order** — numbered list with rationale for top 3 and bottom 3 features.
</output_format>
Before writing, identify any feature that should ANCHOR top-of-list because of the forcing context.Example
Common pitfalls
- Model defaults to L/M/H instead of integers — forces ties everywhere. Demand integer scoring.
- Weights get ignored if not surfaced in the output; some downstream readers won't know how the total was computed.
- Defect history defaults to 'medium' for everything without source data — be explicit when feeding the prompt.
- Tie-break rule gets forgotten when not enforced; matrix has ties that aren't broken.
Tips
- Run this once per release; the rankings drift as features age (defect history changes, usage shifts).
- Feed actual production usage data when available (page views, API calls) — usage frequency scores improve dramatically.
- Share the matrix with PM and engineering BEFORE prioritizing test work — alignment is faster than negotiation later.
- Pair with `generate-test-strategy` so risks at the strategic level connect to this matrix's tactical priorities.
FAQ
ISO 29119 lists impact, complexity, and usage as standard risk factors. Defect history is empirical — it tells you where bugs HAVE come from, which predicts where they'll come from. Adding more dimensions usually doesn't change the ranking but adds noise.
Related prompts
Generate Test Strategy Document
Returns a full Test Strategy document with 8 mandatory sections — scope, test levels, test types, entry/exit criteria, risk matrix, environment, resources, deprioritized test types — tailored to a product description and stated constraints.
Open →Create Test Plan from PRD
Reads a Product Requirements Document and returns a release-specific Test Plan with scope, milestones, RACI per major activity, deliverables, entry/exit criteria, risk assessment, and a defect management workflow. Uses date placeholders the user fills rather than fabricating.
Open →Test Pyramid Design for Microservices
Reads a microservices topology (services + integration points) and returns a recommended pyramid distribution with concrete percentages per layer, layer-by-layer justification, explicit contract-test placement at every service boundary, and a strategy for async events.
Open →Test Estimation from User Stories
Reads a backlog of user stories and returns testing effort estimates broken down by activity (test design, execution, automation, reporting) with a confidence level (high/medium/low) and a sanity-check flag when total testing exceeds 50% of dev estimate.
Open →