mcpField
Q
qa-quality-perspective

qa-quality-perspective

github.com/naodengTesting & quality28542 installsUpdated 1d ago
Repository

About qa-quality-perspective

qa-quality-perspective is a skill for evaluating testability, coverage, defects, and quality risk at QA stages. It distinguishes supplied evidence from inference and avoids claiming that tests ran or passed without execution records.

Key features

  1. 01Eight supported quality stages
  2. 02Stage-specific prompt selection
  3. 03Testability and risk assessment
  4. 04Evidence and inference separation
  5. 05Qualitative risk anchors

Use cases

  1. 01Identifying gaps in requirements testability
  2. 02Reviewing risk-based test coverage
  3. 03Reporting untested scope and quality risks

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/naodeng/awesome-qa-skills --skill qa-quality-perspective

After installing, type/qa-quality-perspectivein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/
openai.yaml
evals/
eval.yaml
evals/cases/
basic-code-review.yaml
basic-requirements-analysis.yaml
basic-test-case-review.yaml
basic-test-case-writing.yaml
basic-test-strategy-review.yaml
basic-test-strategy.yaml
edge-condition-not-met.yaml
edge-insufficient-evidence.yaml
edge-role-boundary.yaml
edge-role-conflict.yaml
edge-unsupported-stage.yaml
review-test-report-review-raw-results.yaml
review-test-reporting-raw-results.yaml
prompts/
code-review.md
requirements-analysis.md
test-case-review.md
test-case-writing.md
test-report-review.md
test-reporting.md
test-strategy-review.md
test-strategy.md

Details

From the project README

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.
stageOnly Prompt to load
requirements-analysisprompts/requirements-analysis.md
test-strategyprompts/test-strategy.md
test-strategy-reviewprompts/test-strategy-review.md
code-reviewprompts/code-review.md
test-case-writingprompts/test-case-writing.md
test-case-reviewprompts/test-case-review.md
test-reportingprompts/test-reporting.md
test-report-reviewprompts/test-report-review.md

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.

Report provenance

Keep the selected stage, a stable source_id, and supplied version in the report header. If a source ID is absent, declare a temporary local locator; if version is absent, write unknown rather than inventing it. Each finding has a stable finding_id, its source/evidence locator and status. Each action links its finding and specifies the evidence that would close it; owner, date and action status stay unknown unless supplied. These are standalone report fields, not a dependency on another Skill.

Qualitative risk anchors

Use impact, observed likelihood signals, and uncertainty together; this is judgment, not arithmetic multiplication or a new score. Unknown likelihood stays unknown.

RiskImpact and likelihood evidenceUncertainty/action
HighCritical loss, blocking defect, or critical untested path; credible recurrence or unresolved exposureMissing critical evidence prevents a confident low-risk claim; prioritize verification/escalation
MediumBounded impact or partial evidence with a plausible failure pathState the missing evidence and targeted follow-up
LowLimited impact with supporting control evidence; no supplied critical exposureState residual limits; do not equate low risk with release approval

Comments

Markdown supported