manual-test-case-creator

name

manual-test-case-creator

description

Write full manual test cases executable by ANOTHER tester with zero tribal knowledge — each case has an id, requirement/risk trace, role/persona, environment, preconditions, exact test data, numbered steps with ONE observable expected result per step, screenshot checkpoints referenced to the evidence rules, pass/fail criteria, and cleanup. Cases cover happy, negative, and boundary paths and stay implementation-agnostic (what the user does, not what the code does). Use when asked to write manual test cases or scripts, turn acceptance criteria into an executable manual pass, build the manual regression checklist for judgment-dependent surfaces, or when a release needs a repeatable human verification pass. Do NOT use to EXECUTE a walkthrough now (clickthrough-test-engineer), define evidence naming/masking policy (screenshot-evidence-planner), write automated tests (engineer skills), or decide what should be manual vs automated (qa-strategy-architect / test-plan-designer).

Manual Test Case Creator

Purpose

Produce manual test cases that transfer: a tester who has never seen the feature can pick one up, prepare, execute, and reach the same verdict the author would. The bar is executability by a stranger — every case names its data, role, environment, and per-step expected results, with screenshot checkpoints where evidence is needed. Cases are documents (a reusable library), not a live session.

Use When

• Use when: asked to write manual test cases, manual QA scripts, or a manual regression checklist.
• Use when: a test plan marks items "manual" (visual quality, judgment calls, flows not worth automating) and those items need executable cases.
• Use when: acceptance criteria must become a repeatable human verification pass for each release.
• Do NOT use when: someone should click through the app NOW and report — clickthrough-test-engineer (it may execute THESE cases).
• Do NOT use when: defining how screenshots are named/masked/stored — screenshot-evidence-planner; cases REFERENCE those rules.
• Do NOT use when: the ask is automated tests — the engineer skills.
• Do NOT use when: deciding the manual-vs-automated split — that decision arrives from qa-strategy-architect/test-plan-designer; this skill writes the manual side.

Inputs to Inspect

1. The requirement/acceptance criteria/plan items each case will verify — every case traces to one; orphan cases are scope creep.
2. The actual UI as built (routes, labels, flows) — steps reference what a tester will really see; if the UI is unbuilt, cases target the spec and say so.
3. Personas/roles and how a tester obtains them (test accounts, seeds from test-data-architect).
4. Evidence rules (screenshot-evidence-planner output) for checkpoint references; note their absence if missing.
5. Environment(s) the pass runs against and any environment-specific behavior.

Workflow

1. List the cases before writing any. From the plan/criteria: happy, negative, and boundary cases per behavior, each with an id and a requirement trace. Confirm the list covers the manual scope — then write.
2. Write preconditions as setup a stranger can perform: exact role, exact starting state, exact test data (values, not "some valid input"), environment, and how to get each (seed script, test account naming).
3. Write numbered steps with one action and one observable expected result each. "Click Save → the dialog closes and the invoice list shows the new row with status Draft." No compound steps, no "verify it works," no implementation language (API calls, DB rows) — observable UI outcomes only. Template in references/manual-case-template.md.
4. Mark screenshot checkpoints at the steps whose outcome is evidence- worthy (per the evidence rules): checkpoint id, what must be visible, masking note.
5. Define the verdict: pass = every step's expected result observed; fail = cite the first failing step + capture evidence; blocked = named missing precondition. No "partial pass".
6. Write cleanup returning the environment to neutral (delete created records, revoke invites) so the next case/run starts clean.
7. Dry-run the case mentally as a stranger (or execute via clickthrough-test-engineer if a session is in scope): every noun defined? every step observable? every datum provided? Fix gaps, then file the cases into the library with their traces.

Output Format

MANUAL TEST CASES — <feature/scope>
Coverage summary: <requirement/risk → case ids (happy/negative/boundary)>
Case:
  ID: <MC-###>  Trace: <requirement/plan item>  Priority: <P0-P2>
  Role/persona: <exact>   Environment: <exact>
  Preconditions: <starting state + how to reach it>
  Test data: <exact values / seed reference>
  Steps:
    1. <one action> → Expected: <one observable result> [📸 CP-1: <what+mask>]
    2. ...
  Pass/fail criteria: <verdict rule>
  Cleanup: <restore-neutral steps>
Open gaps: <criteria that could not be cased + why>
Handoffs: <execution → clickthrough-test-engineer / testers;
          evidence policy gaps → screenshot-evidence-planner>

Validation Checklist

• Every case traces to a requirement/risk/plan item.
• Happy, negative, and boundary paths represented per behavior in scope.
• A stranger could execute: roles, data values, environment, and preconditions all explicit — zero tribal knowledge required.
• Each step = one action + one observable expected result.
• Screenshot checkpoints marked with masking notes where applicable.
• Verdict rule stated; blocked ≠ failed ≠ passed.
• Cleanup returns the environment to neutral.
• No automation code written; no live session performed.

Gotchas

• "Verify the page works correctly" is not an expected result — if the author can't name the observable outcome, the case isn't ready.
• Cases written from the spec while the UI diverged produce false failures — check the built UI, or label the case spec-derived explicitly.
• Shared test data across cases creates order dependence (case 3 passes only after case 1 ran) — either isolate data per case or declare the sequence.
• Steps that mention internals ("the API returns 200") aren't executable by a manual tester — translate to what the screen shows.
• A library without traces rots: when the requirement changes, nobody knows which cases to update — the trace field is load-bearing.

Stop Conditions

• No requirement/criteria AND no built UI to derive behavior from → ask; cases invented from a feature name test nothing.
• Acceptance criteria are untestable as written ("intuitive", "fast") → return them for measurable restatement via test-plan-designer rather than writing judgment-free cases against them.
• The manual/automated split is undecided and the ask is "test cases for everything" → get the split from test-plan-designer first; manual cases for what should be automated waste tester time every release.
• Asked to also execute the pass now → that is a session (clickthrough-test-engineer); confirm and hand off.

Supporting Files

• references/manual-case-template.md — the full case template, step-writing rules, verdict/blocked semantics, and a worked example.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the UI/manual cluster.