Story Test Cases

You write the test cases a developer must satisfy and a Product Owner will approve.
Each case must be readable by a PO (plain given/when/then language, no code or
internal jargon) and right-sized — thorough where it matters, not bloated with
trivia.

Reference files live in references/ and the output template is in assets/ — both
sit alongside this SKILL.md. Consult them as you work:

• references/test-design-heuristics.md — how to choose cases: equivalence classes,
  boundaries, state, permissions, failure modes, and the "not over-defensive" rule
• references/good-vs-bad-examples.md — side-by-side sharp vs. vague/bloated cases
• references/coverage-and-traceability.md — mapping every AC to cases; no case
  tests something the story doesn't promise
• assets/test-case-template.md — the exact case structure with a filled example

Workflow

1. Read the story and acceptance criteria completely

Ingest the full Jira ticket, linked Confluence or RFC pages, and attached specs before
writing a single case. List every acceptance criterion (AC) explicitly — number them
so you can reference them in traceability later.

If no ACs are present, stop and ask the requester to supply them. Drafting cases against
a vague story produces the wrong cases.

2. Identify the coverage areas

For each AC, determine which of these areas applies — you will need at least one case
per area that appears:

Use references/test-design-heuristics.md to judge which cases are worth writing and
which to skip. Consult references/good-vs-bad-examples.md when in doubt about a case's
quality.

3. Draft cases using the template

For every case, fill in every field in assets/test-case-template.md:

• title — short, specific, outcome-oriented (e.g., "Reject deposit below minimum")
• category — happy | validation | error | edge
• priority — high / medium / low, driven by user or business impact
• ac-refs — one or more AC numbers this case exercises
• preconditions — the state that must hold before the steps begin
• steps — the actions, in order, in plain language a PO understands
• expected — the observable result: what the user sees and what the system records

Write in the user's vocabulary. Avoid implementation terms (class names, SQL, HTTP
codes) unless they appear in the story's own language.

4. Check coverage and traceability

Using references/coverage-and-traceability.md as your guide, verify:

• Every AC maps to at least one case.
• No case tests a behavior the story does not promise.
• The set collectively tells a coherent story of "working correctly."

Write a one-line traceability note under each case's ac-refs if the link is not
obvious.

5. Produce the final case set

Group cases by category (happy first, then validation, error, edge). Within
each group, order by priority descending.

Prepend a short header: the story title, a one-sentence scope statement, and the total
case count by category. This header is what the PO scans first.

Quality bar

• PO-readable. If a PO cannot read a step or expected result aloud and immediately
  understand it, rewrite it.
• Not over-defensive. Three sharp validation cases beat fifteen that no real user
  will ever trigger. If a case doesn't protect a genuine user or business outcome, cut it.
  See references/test-design-heuristics.md for the explicit "skip" list.
• Unambiguous expected results. Each expected result must state exactly what happens —
  not "the system responds appropriately" but "the user sees error message 'Amount must
  be at least £10'."
• Independent cases. No case should depend on the outcome of another unless you
  explicitly model a flow sequence.
• No invented requirements. If the story is silent on a behavior, leave a marked
  open question rather than asserting an outcome.
• One coherent artifact. The case set you produce is the contract the developer
  implements against. It should be ready to paste into Jira or a Confluence page.