Risk-Based Testing
Use it when business criticality, change surface, past defects, or failure modes must determine test order and depth.
StatusStable
TypeAtomic Skill
DomainSoftware testing
SDLCTest design
Good forQA / PM
LanguageChinese / English
EvalsEvals ✓
Synced2026-09-15
Why this Skill
It turns this Skill's method into a quality input that can be executed, reviewed, and reused.
- 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.
- Listing risks without saying how they change test priority and depth.
When to use
Use this Skill
- 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.
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.
Input
Minimum Input
- The current task scope, objective, and subject under review.
Recommended Input
- Project goal
- Test scope
- Constraints
Optional Context
- Relevant code or configuration
- Historical results
- Logs and metrics
Output
The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.
These are the Skill's expected output requirements, not evidence that it ran in a real project.
- 01Read and follow prompts/risk-based-testing.md, starting with the six-part input audit.
- 02Link risk source, failure mode, impact, likelihood/uncertainty, and detectability to a test objective.
- 03Record priority, level/method, depth, scope tradeoff, and required evidence in RBT-## entries.
- 04Define stop conditions, expansion triggers, residual risk, and Human decisions for constrained work.
View full output structure
- 05Never turn unsupported numbers, risk grades, or test recommendations into facts or execution results.
How It Works
- 01Read and follow prompts/risk-based-testing.md, starting with the six-part input audit.
- 02Link risk source, failure mode, impact, likelihood/uncertainty, and detectability to a test objective.
- 03Record priority, level/method, depth, scope tradeoff, and required evidence in RBT-## entries.
- 04Define stop conditions, expansion triggers, residual risk, and Human decisions for constrained work.
- 05Never turn unsupported numbers, risk grades, or test recommendations into facts or execution results.
Install & Quick Start
Install command / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/risk-based-testing
-grisk-based-testing.prompt
@skill risk-based-testing
Using the current project context, produce an actionable result following this Skill.
Additional context:
[Paste project context or requirement]---
name: risk-based-testing
description: Use this skill when you need to turn quality risks into prioritized test objectives, depth, methods, and scope tradeoffs; triggers include risk-based testing.
---
# 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.