Test Plan Generator

test-plan-generator

Produces a test plan that says what to test first, what to test where (unit vs integration vs e2e), and — the part most plans omit — what is deliberately not tested and why. Downstream of user-story-splitter (its ACs map straight into the coverage table); sibling of feature-implement-loop (which writes the tests this plan prioritizes).

How to respond

1. Ingest the change. Accepts any of: a story/brief with acceptance criteria, a diff or PR, a release scope, or a prose feature description. If given a diff, read it before planning — the plan must name the actual surfaces touched, not generic areas. Ask at most 2 clarifying questions; tag every other unknown [assumption].

2. Rank risks before writing a single test case. Build the risk table first: for each area the change touches, what could go wrong, likelihood (H/M/L), impact (H/M/L), and the resulting priority — P1 (H/H or H/M), P2 (M/M or H/L), P3 (everything else). Test-case effort follows priority: P1 gets concrete cases, P2 gets cases or charters, P3 gets a one-line exploratory note or an explicit "accept the risk".

3. Push each test to the lowest pyramid level that can catch the failure. Unit if the logic is reachable in isolation; integration if the failure lives in a boundary (DB, queue, API contract); e2e only for journeys that genuinely cross systems. ✅ "Discount rounding — unit test on the pricing function" — ❌ "Discount rounding — e2e checkout test" (slow, flaky, and the assert is three layers from the bug).

4. Map every acceptance criterion to at least one test case. Emit the AC → test coverage table; an AC with no row is a finding, not an omission. Where the input has no formal ACs, derive them from the described behavior and tag them [derived].

5. Sweep the edge-case taxonomy against P1/P2 areas — boundaries (0, 1, max, max+1), empty/null/missing, duplicates and idempotency, concurrent access, permission denied, dependency down or slow, clock/timezone/DST, oversized input, unicode. Only write cases for the ones that apply; name the ones skipped as not applicable so the reader sees the sweep happened.

6. Write observable entry/exit criteria. Entry: what must be true to start (env up, test data loaded, feature flag state). Exit: pass/fail conditions a release manager can verdict — ✅ "All P1 cases pass; no open defects of severity major+ in the touched areas" — ❌ "QA signs off".

7. Emit the plan with templates/test-plan.md in one message: scope (in/out), risk table, AC coverage table, test cases grouped by pyramid level, test data + environment needs, entry/exit criteria, and Not tested — accepted risks with a one-line justification each.

Useful references in this skill

• templates/test-plan.md — the full plan skeleton with the risk and coverage tables

Quality bar

• Risk table precedes test cases, and effort tracks priority. A plan that gives equal depth to every area was written by coverage habit, not risk.
• Every test case has a concrete expected result. ✅ "Then the response is 422 with error code DUPLICATE_SKU" — ❌ "Then an appropriate error is shown".
• Every AC appears in the coverage table. Uncovered ACs are listed as gaps at the top of the plan, never silently absent.
• The "Not tested" section is non-empty. A plan that tests everything is a plan that prioritized nothing — naming accepted risks is the deliverable.
• Pyramid placement is justified by failure location, not by what's easiest to write. Each e2e case states why no lower level could catch it.

When to use this skill

• ✅ A feature/story is ready for test planning before or during implementation
• ✅ A PR or release needs a documented QA pass and exit criteria
• ✅ "How should we test this?" for a risky change (migration, payment flow, auth)
• ✅ Turning user-story-splitter output into a test strategy for the sprint

When NOT to use this skill

• ❌ Writing the test code itself — hand the plan to feature-implement-loop or a human
• ❌ Adversarial review of code already written — that's devils-advocate
• ❌ Static-analysis or quality-gate findings — that's sonar-review
• ❌ A trivial change (typo, copy edit) — the plan would cost more than the risk

Anti-patterns to avoid

• ❌ Coverage theater. Fifty shallow cases that all walk the happy path while the one migration risk gets a single line.
• ❌ "Verify it works correctly" as an expected result. If a new tester couldn't verdict pass/fail from the words alone, rewrite it.
• ❌ Everything at e2e level. The slowest, flakiest layer should hold the fewest tests, not the whole plan.
• ❌ Omitting the not-tested list because it feels like admitting weakness. Unstated gaps get discovered in production; stated ones get a conscious decision.
• ❌ Test data as an afterthought. "Use prod-like data" is not a data plan — name the records, states, and volumes the P1 cases need.
• ❌ Exit criteria that name people instead of conditions. Sign-off follows the criteria; it isn't one.