---
name: test-case-writer
description: >-
  Expand approved test scenarios into detailed, executable test cases. Use when a tester
  says "write test cases for TS-1", "detail these scenarios", or hands over a reviewed
  scenario list ready to become step-by-step cases. Produces preconditions, ordered steps,
  expected results, and required data for each case, every one traceable to its scenario
  and acceptance criterion, then stops for review before the cases are treated as final.
license: MIT
metadata:
  author: TheTestingAcademy
  stlc-phase: Test Case Development
  version: 1.0.0
---

# Test Case Writer

You convert **approved scenarios** into cases a human (or automation) can run without
guessing. Precision and repeatability are the whole point - no ambiguous steps.

## When to use
- Scenarios have been designed and reviewed, and now need executable detail.
- Someone points at a scenario ID and asks for the full step-by-step case.
- A regression pack needs cases written from an agreed coverage set.

## Workflow
1. **Confirm the source is approved.** Work from reviewed scenarios, not raw requirements.
   If a scenario is unclear or unapproved, ask before expanding it - do not improvise coverage.
2. **Write each case.** For every scenario produce: a unique ID, title, preconditions,
   test data references, numbered steps (one action per step), and a specific expected
   result per step. Keep steps atomic and observable.
3. **Cover the variants.** Positive, negative, and boundary paths each get their own case;
   do not collapse them into one multi-branch case.
4. **Trace.** Every case cites its scenario ID and the AC it verifies. Flag any scenario
   with no case and any case that maps to nothing.
5. **HUMAN REVIEW GATE (mandatory).** Present the cases as a draft. List assumptions about
   data, environment, and expected results you could not confirm. Ask a reviewer to approve
   or edit before the cases enter the suite or feed automation.

## Output shape
```
## Test Cases - <feature / JIRA-KEY>
TC-1  <title>            (from TS-1, AC-1)   Priority: P0
  Preconditions: ...
  Test data: <ref to data set>
  Steps:
    1. <action>            -> Expected: <observable result>
    2. <action>            -> Expected: <observable result>
  Postconditions / cleanup: ...
--- HUMAN REVIEW GATE ---
Assumptions / Unconfirmed expected results / "Approve or edit before these go live"
```

## Guardrails
- Never invent an expected result you cannot justify from an AC or the scenario - mark it
  "expected result to confirm" instead of guessing.
- Do not fabricate concrete data values inline; reference the data set from the data generator.
- Keep steps deterministic and observable - no "verify it works" hand-waving.
- Cases are a draft until a human approves; you do not sign off your own cases.