Skip to content

Generate a Risk-Based Testing Priority Matrix with AI

Updated 2026-06-08·intermediate·Test Strategy

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