authoring-test-plan — SKILL.md

Variant: standard · When to use: authoring (or amending) the QA / verification plan for a project — to a bar where a tester executes it with no further questions, every behavior has at least one traceable case, the catalog is risk-weighted not combinatorial, and the warranted non-functional testing carries numeric targets.

Overview

This skill is the how-to of writing a strong test plan (QA / verification plan) — the document that says what to test, at what level, in what environment, with what data, to what done-criteria, and the concrete cases to run. It spans the strategy (scope, functional test levels & types, coverage approach, non-functional testing, environments + test data, entry/exit criteria, risk-based prioritization) and an enumerated test-case catalog (each case: id, preconditions, steps, expected result, traceability), plus amending an approved plan as a versioned delta. This skill carries the producer's judgment — the research method and the quality bar — not the section list. It assumes two collaborators: a test-plan template tool that supplies the section structure, and a deep-research capability to ground the plan in established test-strategy practice. The producer is handed the upstream documents (typically the feature-spec whose behaviors the cases verify, the api-spec whose operations + errors they exercise, the PRD whose acceptance the exit criteria tie to, and the NFRs/architecture-doc the non-functional testing targets) — never a blank page. The bar: a tester executes the plan with no further questions — every supported behavior has a traceable case, the levels + environments + data are stated, the exit criteria are testable, the warranted non-functional testing carries numeric targets, and the catalog is sized by risk, not padded and not thin.

When to activate

• Authoring a test plan / QA verification plan from an approved feature-spec (+ api-spec / PRD / NFRs) that names the behaviors the system must satisfy.
• Specifying the functional levels & types, coverage approach, non-functional testing, environments + test data, entry/exit criteria, risk prioritization, and the test-case catalog.
• Amending an approved plan against a change request (an upstream behavior changed/added/removed, or a discovered defect) — a versioned delta, not a redraw (see Step 8).
• Filling a test-plan template with researched, traceable, risk-weighted per-behavior coverage and executable cases.

Do NOT activate when: