Risk-Based Testing

Translate supplied quality risks, failure modes, and delivery constraints into evidence-backed test priority, level/method, depth, and scope tradeoffs. Produce RBT-## decisions. This is not a full test strategy; it does not replace risk analysis or regression selection, and it does not execute tests.

When to Use

• Use it when business criticality, change surface, past defects, or failure modes must determine test order and depth.
• Use it when time, environment, or capacity is constrained and the tradeoffs between focus, sampling, and deferral must be explicit.
• Use it when risk evidence is incomplete but a bounded priority view with assumptions and triggers is useful.

Do not use it only to identify quality risks, write a complete test strategy, select an existing executable set, or announce release readiness.

Output Format Options

• Use Markdown by default; when a table, CSV, or JSON is requested, preserve the same evidence, status, impact, owner, and validation fields.
• Do not present a structured format or static inventory as execution, pass, approval, or release evidence.

How to Use

1. Read this Skill's primary prompt and provide the objective, scope, material, environment, and available evidence.
2. Follow the prompt's input audit and output contract; deliver a bounded first pass when information is incomplete.
3. Retain source, evidence status, impact, owner role, close condition, and validation method for every finding.

Workflow

1. Read and follow prompts/risk-based-testing.md, starting with the six-part input audit.
2. Link risk source, failure mode, impact, likelihood/uncertainty, and detectability to a test objective.
3. Record priority, level/method, depth, scope tradeoff, and required evidence in RBT-## entries.
4. Define stop conditions, expansion triggers, residual risk, and Human decisions for constrained work.
5. Never turn unsupported numbers, risk grades, or test recommendations into facts or execution results.

Core Constraints

• RBT-## is a test-decision recommendation, not risk acceptance, a quality score, coverage proof, or release approval.
• Risk ratings need evidence and assumptions; without data, use qualitative levels and state uncertainty rather than pseudo-precise numbers.
• Do not generate a full test strategy or replace quality-risk-analysis, test-strategy, or regression-test selection.
• Do not select concrete existing test IDs, execute tests, or invent environments, thresholds, defects, or pass results.

Reference Files

• Always read prompts/risk-based-testing.md before producing an analysis.
• For regression, read evals/eval.yaml and its cases; configuration and recommendations do not prove that risks are controlled.
• For trigger checks, use evals/trigger-prompts.csv and evals/local-rules.json; missing selection trace is BLOCKED.

Best Practices

• Prioritize high-impact gaps with a verifiable next action, using the smallest useful experiment or evidence request.
• Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade an assumption into a conclusion.

Pre-delivery Check

• Recorded known facts, missing information, conflicts, stale information, out-of-scope items, and assumptions.
• Each RBT-## has risk source, test objective, level/method, depth, priority basis, and required evidence.
• Tradeoffs have impact, stop conditions, expansion triggers, and residual risk.
• Test recommendations, risk inference, execution evidence, and Human decisions are separate.
• A limited scope is not presented as full coverage, zero risk, or release approval.

Common Pitfalls

• Listing risks without saying how they change test priority and depth.
• Using a risk score instead of evidence and tradeoff rationale.
• Turning a full strategy, regression set, or execution result into this Skill.
• Silently dropping a high-risk area under time pressure without an expansion trigger or residual-risk statement.