A QA quality perspective should not only total up test execution. It must identify evidence gaps, exposed risk, and whether the release decision is honest. Tests completed does not mean risk is managed.
The QA Quality Perspective Skill turns coverage and findings into a transparent quality narrative that leaders and delivery teams can act on.
A checkout regression example records the build, command, exit code, verified paths, static-only checks, unrun cases, and blockers separately.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with QA quality perspective.
Read the source Skill first
The main prompt covers Allowed inputs, Applicability and QA checks, Evidence and risk, Output structure, Inputs. Those headings are navigation; the project artifacts still provide the facts.
This Skill has no separate examples directory. The sample below is derived from its entry point, main prompt, and eval constraints.
Related Skills
QA Quality Perspective explains what was covered, what was not, and whether the evidence supports a release judgment. Adjacent work can be divided as follows:
| Skill | When to use it | What it adds |
|---|---|---|
| Regression Test Selection | Change scope is known and cases must be selected | Chooses a regression set using risk, dependencies, and historical results |
| Test Reporting | Command output and reports need to be communicated | Standardizes run identity, outcomes, failure evidence, and coverage boundaries |
| Multi-Role Quality Synthesis | QA conclusions must be combined with Product, Technical, and UX views | Preserves disagreements and responsibility boundaries |
| Technical Quality Perspective | Static findings need to be connected to runtime signals | Adds dependency, performance, observability, and recovery evidence |
| Project Delivery Perspective | Test windows, dependencies, or actions affect commitments | Tracks delivery constraints without rewriting test facts |
What QA Perspective contributes across the workflow
Product, QA, and UX can review the same membership-upgrade change. QA turns the questions into “Can it be tested? What ran? Where is the evidence?” Stage names may match, but outputs and risks differ.
| Stage | What QA checks | What the team receives |
|---|---|---|
| Requirements analysis | Whether behavior, boundaries, failure handling, observable outcomes, data, and environment are testable | Testability gaps, risk, owner, and evidence request |
| Test strategy | Risk order, test levels, dependencies, data, environment, observability, and exit criteria | Coverage priorities, methods, evidence needed, and exclusions |
| Test strategy review | Whether trade-offs, entry/exit evidence, degradation risks, and owners are clear | Prioritized findings, rationale, and revisions |
| Code review | Whether test entry points, observable outcomes, error handling, and regression evidence exist | Static findings, risks to verify, and smallest runtime evidence |
| Test case writing | Whether preconditions, inputs, steps, expected results, positive/negative paths, and data isolation are executable | Prioritized case suggestions and evidence needs |
| Test case review | Whether cases are executable, decidable, traceable, and cover boundaries and exceptions | Case defects, coverage gaps, and revisions |
| Test reporting | Actual scope, execution state, result, defects, environment differences, and unrun items | Facts, inferences, missing evidence, risk, and next steps |
| Test report review | Whether conclusions trace to run records and risk categories match impact | Review findings; review comments do not become run passes |
A QA report is evidence engineering: summary, facts, evidence, inference, testability, risk-based coverage, defects and quality risk, missing evidence, recommendations, next steps, and confidence all need sources. A passed result covers only what ran; it cannot stand for the entire membership-upgrade flow.
Separate the three perspectives on one input
| Shared input: delayed payment callback | Product Quality Perspective | QA Quality Perspective | UX Quality Perspective |
|---|---|---|---|
| Requirements, PR, regression record, payment logs, timeout recording | Confirm waiting rules, duplicate-charge risk, and business approver | Mark timeout, retry, and reconciliation as verified, not_run, or blocked | Check processing/timeout feedback, focus, copy, and recovery |
Checkout regression: what did the evidence cover?
Review a checkout change through testability, coverage, and evidence. Break “tests passed” into items that can be checked.
| Scope | Evidence available | Release interpretation |
|---|---|---|
| Main path | Automation result, build ID, and order state | Describes this run only |
| Payment callback | Successful example only; no timeout record | Evidence gap; do not call it covered |
| Permission boundary | 403 case passed; data isolation was not checked | Add different accounts and resource ownership |
| Data cleanup | Test account still has residual orders | Blocks repeatability and review |
A QA conclusion should name coverage limits, residual risk, follow-up tests, and who accepts the risk.
Tie a release recommendation back to evidence
A green regression means only that the selected cases passed with this environment and data. Record each uncovered item as a risk, impact, follow-up action, and accepter.
| Open risk | Impact | Next action | Accepter |
|---|---|---|---|
| Payment timeout not covered | Duplicate submission or a stuck order may occur | Add timeout, retry, and reconciliation cases | Product and payment owners |
| Test data not cleaned | The next run may not be reproducible | Add setup and cleanup steps | Test owner |
| Production configuration not verified | Environment differences may change behavior | Add smoke evidence in the target environment | Release owner |
Evidence gaps need a source and time window. The Skill organizes the quality account; the release owner accepts or closes risk.
Turn QA evidence into a handoff
| Development step | QA action | Material to retain | Next owner |
|---|---|---|---|
| Requirements analysis | Check whether acceptance criteria are testable and key boundaries observable | Requirement version, scope, unknown rules, risk assumptions | Product and development |
| Test strategy | Allocate coverage by change impact and failure cost | Risk matrix, case set, environment and data plan | Test executor |
| Regression execution | Record actual runs rather than a screenshot of “passed” | Build ID, command, exit code, report, failure artifacts | QA lead |
| Release handoff | Separate covered, static-only, unrun, and blocked work | Evidence index, residual risk, owner, due time | Release owner |
For a checkout change involving callbacks and order permissions, the run record should identify the build, environment, data, command, exit code, and exception cases that did not run.
run_id: checkout-regression-2026-09-24-01
source_version: build-2026-09-24-01
environment: staging
data: fresh-user + existing-order + duplicated-callback-fixture
command: npm run test:e2e -- checkout
exit_code: 0
verified:
- Checkout, successful payment, and order lookup on the main path
- 403 permission response
static_only:
- Production payment configuration has not been checked in the target environment
not_run:
- Retry and reconciliation after payment timeout
blocked:
- Cleanup task failed; residual orders need handling
artifacts:
- reports/checkout/index.html
- logs/payment-timeout-not-run.md
owner: QA lead
next_action: Add timeout and duplicate-callback cases, clean test orders, then rerun
status: pendingVerified describes only paths with run evidence. static_only means the evidence came from reading code or configuration; not_run means no execution occurred; blocked means the planned work was stopped by environment, data, or infrastructure. These states cannot be combined into one green number.
Adaptable prompt
Use the qa-quality-perspective Skill.
Stage: test report review (test-report-review)
Task: Review a checkout change for testability, coverage, and evidence
Version and environment: [requirement / build / environment]
Inputs: [file paths or links]
Scope: [included and excluded journeys]
Constraints: [accounts, data, time, compliance]
Report summary, facts, evidence, inference, testability, risk-based coverage, defects and quality risk, missing evidence, recommendations, next steps, and confidence. Record run_id, version, environment, command, exit code, and actual coverage. Keep verified, static_only, not_run, and blocked separate. Do not report unexecuted work as passed or as release approval.State what the evidence covers—and what it does not
A passing checkout regression proves only the result for its environment, data, and cases. List the main path, exception recovery, permission boundaries, and data cleanup separately, with each state marked as run, static-only, unrun, or blocked.
Who should use this Skill
QA leads can prepare release reviews with it. Project owners can check whether a “pass” has a clear boundary. Engineering and Operations can use the findings to add logs, cleanup, or environment checks.
Review QA evidence before handoff
| Review item | What to retain | If missing |
|---|---|---|
| Run identity | run_id, version, environment, time window, command, and exit code | Do not claim the run is traceable |
| Actual coverage | Executed, static-only, unrun, and blocked paths | Preserve separate states |
| Evidence index | Reports, logs, screenshots, traces, failure artifacts, and data scope | State the evidence gap and its impact |
| Residual risk | Unrun or failed items, impact, and acceptance condition | Keep it open |
| Action owner | Smallest follow-up test, owner, and due time | Do not report a recommendation as a completed fix |
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/qa-quality-perspective -gInvoke it with “Use the qa-quality-perspective Skill,” then attach the real artifacts.
Common questions
Can a fully green pipeline approve release by itself?
First check coverage, environment, data, and failure evidence. Missing critical paths still leave limited evidence.
What if I only have static-check results?
Mark them static-only or pending and list the smallest runtime action. Do not rewrite them as a pass.
What if nobody accepts a risk?
Keep the risk and impact visible and name the owner who must decide. Without an accepter, do not archive it as resolved.
What should a quality conclusion retain?
Keep the input version, command, report, failure samples, and human changes so the next reviewer can assess whether the conclusion still holds.
Run QA Quality Perspective against one real regression record and retain run identity, coverage state, output, and review notes. The example provides structure; project evidence must come from the project.
References
- Awesome QA Skills project:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills series overview:https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/
- Awesome QA Skills: QA quality perspective Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/qa-quality-perspective
- QA quality perspective Skill details:https://inaodeng.com/en/qaskills/qa-quality-perspective/