test-plan-designer

name

test-plan-designer

description

Design the concrete test plan for ONE feature, change, or release — the requirement/risk being verified, in-scope and out-of-scope items, the test-layer split for THIS change (what is automated at which layer, what is manual), test data needs, environment assumptions, entry/exit criteria, named artifacts, and CI placement. Every planned test traces to a requirement or risk; the plan is executable by someone who didn't write it. Use when asked to write a test plan for a feature/release/bugfix, to decide what testing a specific change needs before it ships, or to turn acceptance criteria into a verification plan. Do NOT use for the product-wide QA strategy (qa-strategy-architect), for auditing existing coverage (test-coverage-mapper), for writing the manual case steps themselves (manual-test-case-creator), or for implementing the tests (the engineer skills).

Test Plan Designer

Purpose

Produce an executable test plan for a single feature, change, or release: what will be verified, at which layer, with what data, in which environment, and what "done testing" means. The plan instantiates the product QA strategy (qa-strategy-architect output) for one change — it names the tests to build and hands each group to the right engineer skill; it does not implement them.

Use When

• Use when: asked to write a test plan for a named feature, release, or fix.
• Use when: acceptance criteria exist and need to become a verification plan.
• Use when: a risky change (schema, auth, payment) needs its testing scoped before implementation starts.
• Do NOT use when: the ask is product-wide testing rules — that is qa-strategy-architect.
• Do NOT use when: the ask is "what do existing tests cover" — that is test-coverage-mapper.
• Do NOT use when: the ask is to write the step-by-step manual cases — the plan names WHICH manual cases exist; manual-test-case-creator writes them.
• Do NOT use when: the ask is to implement tests — hand off to vitest-unit-component-engineer, integration-test-designer, api-contract-test-designer, or playwright-e2e-engineer per the plan.

Inputs to Inspect

1. The requirement: spec, ticket, acceptance criteria, or the diff/PR if the change already exists. No requirement and no diff → Stop Conditions.
2. The QA strategy (qa-strategy-architect output) if present — the plan must follow its layer rules and evidence classes; deviations are called out.
3. The change classification (change-classification-gate output if present) — it sets the validation floor.
4. Affected surfaces: routes, APIs, schema, jobs, integrations touched by the change; existing tests already covering adjacent behavior.
5. Test data and environment reality: what fixtures/seeds exist (test-data-architect output), what environments are actually available.

Workflow

1. Name the requirement and the risks. Every plan starts with what could break and why it matters. Risks the change does NOT touch go in out-of-scope with a sentence of rationale.
2. Derive test items from risks, not from the UI tree. For each risk: the behaviors to prove (happy path, negative path, boundary), per the catalog in references/test-plan-template.md.
3. Assign each item the cheapest reliable layer (strategy rules): unit / integration / contract / E2E / manual. The automation-vs-manual split is explicit. Cross-tenant and authorization negatives are delegated to the shipped multi-tenant-security-tester, referenced as plan line items.
4. Specify data and environment per item: which fixtures/personas (delegate design gaps to test-data-architect), which environment, and any masking needs for evidence.
5. Define entry and exit criteria: what must be true to start (build green, migration applied) and to finish (all planned items pass, no open sev-1/2, evidence attached). Exit criteria are objective.
6. Name artifacts and CI placement: which items run in CI (and in which tier) vs pre-release manual passes; which artifacts each produces (reports, screenshots per screenshot-evidence-planner conventions).
7. Hand off implementation: map each plan group to its engineer skill and list open questions that block execution.

Output Format

TEST PLAN — <feature/change/release>
Requirement & risks: <what is being verified; ranked risks>
In scope / out of scope: <items + rationale for exclusions>
Test items:
  <id> — <behavior to prove> — layer <unit|integration|contract|e2e|manual>
       — data <fixture/persona> — env <assumption> — expected <objective result>
Automation/manual split: <explicit summary + why per manual item>
Security negatives: <delegated items → multi-tenant-security-tester / rls-policy-auditor>
Entry criteria: <objective preconditions>
Exit criteria: <objective completion conditions>
Artifacts: <named outputs; screenshot checkpoints where applicable>
CI placement: <which items run on PR / merge / nightly / pre-release manual>
Handoffs: <plan group → engineer skill; open questions>

Validation Checklist

• Every test item traces to a named requirement or risk.
• Out-of-scope list exists with rationale (empty scope-cuts are silent lies).
• Each item has layer, data, environment, and an objective expected result.
• Automation/manual split is explicit; each manual item says why manual.
• Entry and exit criteria are objective (a stranger could adjudicate them).
• Artifacts named; screenshot checkpoints listed where UI is affected.
• CI placement stated per item group.
• Security negative testing delegated, not re-specified.

Gotchas

• Plans derived from the UI tree ("test every screen") instead of risks produce huge, shallow plans that miss the one migration that loses data.
• "Exit criteria: QA signs off" is not objective — name the passing items, severity threshold, and required evidence instead.
• A plan whose every item is E2E is a strategy violation — push items down to the cheapest reliable layer or record why not.
• Untestable acceptance criteria ("should be fast", "should be intuitive") must be flagged and made measurable, not silently planned around.
• Plans that assume environments or fixtures that don't exist fail at execution — verify availability during planning, not after.

Stop Conditions

• No requirement, no acceptance criteria, AND no diff to infer behavior from → ask for the requirement; a plan cannot be invented from a feature name.
• Acceptance criteria contradict the observed code behavior → route to source-of-truth-reconciler before planning against either.
• The change is unclassified and touches schema/RLS/security → request classification (change-classification-gate) first; the validation floor changes the plan.
• Asked to also execute the plan in the same pass → execution is a separate step by the named engineer skills; confirm scope first.

Supporting Files

• references/test-plan-template.md — the full plan template, behavior catalog (happy/negative/boundary prompts), and exit-criteria examples.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the strategy/plan/coverage cluster and against multi-tenant-security-tester for security-test asks.