Quality Risk Analysis: Identify, assess, and prioritize the risks that matter
It is easy to list a long set of release risks. The hard part is deciding which ones deserve test effort first and which must be accepted or mitigated. Labeling everything P0—or assigning a precise score to a claim with little evidence—leaves the team without a basis for the trade-offs that matter.
The Quality Risk Analysis Skill brings the discussion back to facts. Each risk connects to a trigger, affected scope, available evidence, mitigation action, and risk accepter. The point of ranking is not a polished scorecard; it is to direct test capacity toward the issues most likely to change a release decision.
Using a membership-upgrade release, this guide shows how to collect business, technical, data, and experience risks; mark assumptions and unknowns; and hand the analysis to the people responsible for verification and decisions.
Quality Risk Analysis Skill: what it is for
Quality Risk Analysis is for work that needs a clear, handoff-ready testing judgment. It keeps project material, the basis for each decision, and the next action on the same trail—so a reader can see what to inspect before choosing how to execute and review it. This guide works through one concrete scenario and keeps human decision boundaries visible.
Start with the source Skill
The complete execution contract lives in Quality Risk Analysis prompt. The source directory also contains 3 evaluation cases for checking whether an output follows the contract.
The entry point calls out these constraints:
- attach evidence and assumptions to scores
- avoid false precision
- explicitly accept or mitigate risks testing cannot remove
Begin with project facts
Put the material you have on the table. Gaps may remain; their status needs to stay explicit.
| Material | What to provide | What to do when it is missing |
|---|---|---|
| Goal and scope | Assess business, technical, data, and experience risk for a membership-upgrade release and rank it by impact and detectability | Name journeys outside this pass |
| Version and environment | Requirement version, build, environment, time window | Stay in design or analysis mode |
| Evidence | Requirements, interfaces, logs, metrics, traces, or defects | Separate facts, assumptions, and open questions |
| Decision boundary | Risk approver and actions that are not authorized | Name the owner and next step |
Use a request like this:
Use the quality-risk-analysis Skill.
Task: Assess business, technical, data, and experience risk for a membership-upgrade release and rank it by impact and detectability
Inputs: [versions, links, log paths, or reports]
Scope: [included and excluded objects]
Constraints: [time, data, permissions, compliance]
Audit the inputs first. Order results by risk and evidence strength. Label unsupported claims as assumptions and give a validation method.Make the result usable by the next person
| Output field | Why it exists | Example status |
|---|---|---|
| Finding or judgment | Describes observed behavior, difference, or risk | Confirmed / Assumption / Open |
| Basis | Points to a version, log, trace, test, or requirement | source_id or link |
| Impact | Explains affected users, journeys, or release decision | P0, P1, or accepted residual risk |
| Next action | Names verification work and an owner | Owner, date, expected evidence |
Do not write “passed” without a run record, query result, or source artifact. Static analysis and runtime proof are different things.
Run one focused pass
Start with a bounded pass—Assess business, technical, data, and experience risk for a membership-upgrade release and rank it by impact and detectability. Put the input version, time window, and accountable owner in one place. Then link each judgment to an artifact. Finish with one validation action that can change the decision.
Risk items need triggers, evidence, mitigation, and an accepter instead of a list of names. The handoff should include an evidence index, assumptions that still need checking, and an action the next person can run without reconstructing the conversation. Plain work. It holds up.
Run one focused pass
Start with a bounded pass—Assess business, technical, data, and experience risk for a membership-upgrade release and rank it by impact and detectability. Put the input version, time window, and accountable owner in one place. Then link each judgment to an artifact. Finish with one validation action that can change the decision.
Risk items need triggers, evidence, mitigation, and an accepter instead of a list of names. The handoff should include an evidence index, assumptions that still need checking, and an action the next person can run without reconstructing the conversation. Plain work. It holds up.
Advanced use: turn one analysis into a maintained mechanism
Risk items need triggers, evidence, mitigation, and an accepter instead of a list of names.
Keep input versions and source IDs with every result. When requirements, code, environment, or data change, recompute only affected judgments and mark them changed, unchanged, or needs-review. Old conclusions are not new evidence.
A three-Skill chain
quality-risk-analysis → test-strategy → release-testing-workflow
| Handoff | Payload | Receiver check |
|---|---|---|
| Upstream to quality-risk-analysis | Source versions, scope, risk, open items | Staleness and conflicts |
| quality-risk-analysis to downstream | Judgments, evidence index, residual risk, tasks | Executability and ownership |
| Feedback to quality-risk-analysis | Runs, defects, changed facts | Baseline and regression scope |
Hand over a summary, an evidence index, and locations for the source artifacts. That gives the receiver enough context and keeps the trail recoverable.
Team gates
| Gate | Check | Failure action |
|---|---|---|
| quality-risk-analysis input | Version, environment, sources, and owner | Stop and list gaps |
| quality-risk-analysis artifact | Material claims have basis, status, and impact | Return for evidence |
| quality-risk-analysis execution | Command, query, or verification path is repeatable | Classify infrastructure or test issue |
| quality-risk-analysis decision | Residual risk has an accepter and date | Do not enter the next stage |
Common traps
- Listing checks without input conditions, expected results, or evidence.
- Marking every finding high priority and removing the team’s ability to choose.
- Refusing to produce a bounded first pass, or presenting guesses as facts.
- Treating one success or one anomaly as long-term behavior while ignoring repeated trials and version changes.
Two practical questions
Can I start with incomplete input?
Yes. Produce a constrained first pass with known facts, assumptions, gaps, and the smallest validation action. Missing environment, data, or permission cannot support an execution claim.
When is human confirmation required?
The accountable owner must confirm scope trade-offs, risk acceptance, production actions, data permission, and release decisions. The Skill organizes evidence and options; it does not grant authority.
Run Quality Risk Analysis with one real artifact and keep the input, output, human edits, and verification evidence in the same work chain. That is what makes the next change cheaper to assess.
References
- Quality Risk Analysis prompt:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/quality-risk-analysis/prompts/quality-risk-analysis.md
- Awesome QA Skills: Quality Risk Analysis Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/quality-risk-analysis
- Awesome QA Skills on GitHub:https://github.com/naodeng/awesome-qa-skills
- Quality Risk Analysis Skill details:https://inaodeng.com/en/qaskills/quality-risk-analysis/