QA Quality Perspective

QA quality perspective

When to use

Use this at a requirements, strategy, review, test-case, or reporting stage when QA must assess testability, risk-based coverage, defect exposure, and quality risk from available 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 stage inputs and any available requirement, code, test, defect, environment, or execution evidence.

Workflow

1. Validate stage. If it is missing or unsupported, return Not applicable, list supported stages, and request a valid stage; do not generate filler conclusions.
2. Load and follow only the one Prompt mapped to that stage; never combine stage Prompts.
3. Apply that Prompt's input threshold. When materials are insufficient, state facts, gaps, and needed evidence rather than inventing tests, defects, or quality conclusions.
4. Produce a standalone QA quality report that separates facts, evidence, inference, missing evidence, and recommendations.

QA responsibilities and boundary

• Focus on testability, risk-based coverage, observability, test evidence, defect risk, untested scope, and quality risk.
• Treat only supplied material as fact; label inference and missing evidence. Never invent product intent, acceptance rules, implementation behavior, execution records, defects, or metrics.
• QA does not decide product intent, certify code correctness, or approve release. Without execution evidence, it must never infer that testing ran, passed, or verified quality.

Report contract

Unless returning Not applicable, include: Summary, Facts, Evidence, Inference, Testability, Risk-based coverage, Defects and quality risks, Missing evidence, Recommendations and next steps, Confidence. Tie every quality conclusion to evidence; classify risk as high, medium, or low with impact and uncertainty.

Pre-delivery check

• The stage is valid and exactly one matching Prompt was loaded
• Facts, evidence, inference, missing evidence, and recommendations are distinct
• Testability and risk-based coverage are assessed, or the reason they cannot be assessed is explicit
• No missing product intent, implementation fact, or execution result is reported as fact
• Without execution evidence, the report does not imply or claim executed, passed, or verified testing

On-demand loading and pitfalls

• Read only the mapped prompts/ file after stage is valid. Read evals/ for regression work, but never treat eval cases as project facts.
• Do not replace evidence with a generic risk checklist, or present test recommendations, static reading, or stakeholder opinion as a passing execution result.