---
name: test-case-writer
description: "Turn a requirement or user story into clear, executable test cases. Use when asked to write test cases, test scenarios, a test suite for a feature, or to derive tests from acceptance criteria. Produces structured test cases — preconditions, steps, test data, expected results — across happy path, edge cases, and negative cases, plus a coverage note, so a tester (or automation) can run them without guessing."
---

# Test Case Writer Skill

Good test cases are unambiguous and complete: anyone can run them and get the same result, and together they
cover the ways the feature can succeed *and* fail. This skill derives test cases from a requirement or user
story — happy path first, then the edge and negative cases that find real bugs — each written so it's directly
executable.

## Working from a brief

Given a user story or a one-line feature description, **write the test cases anyway** — infer the acceptance
criteria, boundaries, and likely failure modes, labelling assumptions. Always include edge and negative cases,
not just the happy path. Never hand back questions instead of cases.

## Required Inputs

Ask for these only if they aren't already provided (else infer and label):

- **The requirement** — the feature/user story and its acceptance criteria.
- **Inputs & rules** — fields, valid/invalid values, limits, and business rules that define correct behaviour.
- **Scope & environment** — UI/API/both, platforms, and any preconditions (logged-in, data state).
- **Priority** — what matters most (critical paths), so cases can be ordered.

## Output Format

### Test Cases: [feature]

A short intro line, then cases in a table (or per-case blocks for complex flows):

| ID | Title | Type | Preconditions | Steps | Test data | Expected result | Priority |
|---|---|---|---|---|---|---|---|
| TC-01 | Valid login | Happy path | user exists | 1. … 2. … | valid creds | logged in, lands on … | High |
| TC-02 | Wrong password | Negative | user exists | … | bad password | error shown, not logged in | High |
| TC-03 | Empty fields | Negative/validation | — | … | blank | inline validation | Med |
| TC-04 | Max-length input | Edge/boundary | — | … | boundary value | accepted/handled | Med |

Cover, deliberately: **happy path**, **boundary/edge** (empty, max, min, just over/under limits), **negative** (invalid input, wrong state, unauthorised), and any **business-rule** cases.

End with a **coverage note**: which acceptance criteria/requirements each case maps to, and any gaps or risks to flag for review.

## Quality Checks

- [ ] Each case has clear preconditions, numbered steps, the test data, and a single expected result
- [ ] Steps are unambiguous — two testers would execute them identically
- [ ] Coverage includes edge/boundary and negative cases, not just the happy path
- [ ] Cases trace back to the acceptance criteria / requirement (coverage note)
- [ ] Cases are prioritised so the critical paths are obvious
- [ ] Expected results are specific and verifiable (not "works correctly")

## Anti-Patterns

- [ ] Do not write only happy-path cases — the bugs live in the edges and negatives
- [ ] Do not write vague steps ("test the login") — give the exact actions and data
- [ ] Do not use unverifiable expected results ("it should work") — state the observable outcome
- [ ] Do not combine many checks into one bloated case — keep cases atomic and traceable
- [ ] Do not skip preconditions/test data — they're why a case is reproducible

## Based On

Test-design practice — requirement-derived cases with boundary-value and negative testing, atomic executable steps, and traceability to acceptance criteria.