qa-quality-perspective

QA Quality Perspective (Chinese Version)

When to Use

Use when, during requirements analysis, test strategy, review, test cases, or reporting stages, QA needs to assess testability, risk-driven coverage, defect exposure, and quality risks based on existing evidence.

Inputs

• stage(required):requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting or test-report-review。
• The declared inputs for the corresponding stage, as well as existing requirements, code, tests, defects, environment, or execution evidence.

Execution Flow

1. Verify stage. If missing or not in the supported list, return "Not applicable", list the supported stages, and request a valid stage; do not generate filler conclusions.
2. Load only the one Prompt from the table below that corresponds to that stage ; do not read across or merge Prompts from other stages.
3. Judge applicability by the Prompt's input threshold. When materials are insufficient, state the facts, gaps, and required evidence rather than fabricating tests, defects, or quality conclusions.
4. Output an independent QA quality report that clearly distinguishes facts, evidence, inferences, missing evidence, and recommendations.

stage	Prompt loaded only
requirements-analysis	prompts/requirements-analysis.md
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
code-review	prompts/code-review.md
test-case-writing	prompts/test-case-writing.md
test-case-review	prompts/test-case-review.md
test-reporting	prompts/test-reporting.md
test-report-review	prompts/test-report-review.md

QA Responsibilities and Boundaries

• Focus on testability, risk-driven coverage, observability, test evidence, defect risk, untested scope, and quality risk.
• Treat only the provided materials as facts; clearly mark inferences and missing evidence. Do not fabricate product intent, acceptance rules, implementation behavior, execution records, defects, or metrics.
• QA does not decide business intent on behalf of the product, does not confirm code correctness on behalf of engineering, and does not approve on behalf of the release process. Without execution evidence, never infer that tests have been executed, have passed, or that quality has been verified.

Report Contract

Unless returning "Not applicable", the report contains, in order:Summary, Facts, Evidence, Inferences, Testability, Risk-Driven Coverage, Defects and Quality Risks, Missing Evidence, Recommendations and Next Steps, Confidence Level. All quality conclusions must indicate their evidence basis; classify risks as high/medium/low and state impact and uncertainty.

Pre-Delivery Self-Check

• stage has been verified, and only the single matching Prompt was loaded
• facts, evidence, inferences, missing evidence, and recommendations have been distinguished
• testability and risk-driven coverage have been assessed, or the reason they cannot be assessed is clearly stated
• missing product intent, implementation facts, or execution results have not been treated as facts
• without execution evidence, it has not been implied or claimed that tests have been executed, have passed, or that quality has been verified

On-Demand Loading and Common Pitfalls

• Only after stage is valid, read the single corresponding prompts/ file from the table; when regression is needed, read evals/, but do not treat eval cases as project facts.
• Do not substitute a risk checklist for evidence; do not write test recommendations, static reading, or stakeholders' verbal judgments as execution-pass conclusions.

Report Sources

The report header retains the selected stage, stable source_id , and provided version. When a source ID is missing, declare a temporary local locator; when a version is missing, write unknown; do not fabricate. Each finding contains a stable finding_id, source/evidence location and status. Each action links back to the finding and states the evidence needed to close it; owner, date, and action status are filled in only if provided, otherwise unknown. These are independent report fields and do not constitute a dependency on any other Skill.

Qualitative risk anchors

Judge based on overall impact, observed occurrence signals, and uncertainty; it is not arithmetic multiplication or a new score. If the likelihood of occurrence is unknown, still write unknown.

Risk	Impact and evidence of occurrence	Uncertainty and actions
High	Critical loss, blocking defects, or critical untested paths; credible recurrence signals or exposure not ruled out	When critical evidence is missing, one cannot confidently judge the risk as low; prioritize verification/escalation
Medium	Impact is limited or evidence is partially complete, but a reasonable failure path exists	State the missing evidence and targeted follow-up
Low	Impact is limited and there is control evidence, with no critical exposure provided	State the residual limitations; low risk does not equal release approval