The fields that go in a usable test case, with worked examples across positive, negative, boundary, and equivalence-class types. Built so the case still makes sense to the tester who runs it six months from now.
Required fields gate execution. Optional fields support reporting + traceability.
| Field | Required | Description |
|---|---|---|
| Test Case ID | Yes | Unique, traceable identifier — e.g., TC-CO-001 for Checkout case 001. Used in RTM + defect references. |
| Title / Summary | Yes | One-line action-oriented summary. "Verify checkout completes with expired test card declines gracefully" beats "Test 1". |
| Module / Feature | Yes | The system area being exercised. Maps to a feature ID from the Test Plan. |
| Requirement ID (RTM link) | Yes | Source requirement or acceptance criterion. Without this, you cannot prove coverage. |
| Priority | Yes | P0 / P1 / P2 / P3. Drives execution order in time-boxed cycles. |
| Type | Yes | Functional / Non-functional / Regression / Smoke / Exploratory / Negative / Boundary / Security / Accessibility. |
| Preconditions | Yes | State the system must be in before execution — logged-in user, seeded data, feature flag on, etc. |
| Test Data | Optional | Specific inputs the case uses — email addresses, card numbers, file uploads. Reference data sets in test-data fixtures. |
| Test Steps | Yes | Ordered, atomic actions. One verb per step. "Click Pay" not "Click Pay then check email then verify webhook". |
| Expected Result | Yes | The observable, verifiable outcome. "Order is created" is weak; "Order #ABC123 appears in /orders with status=PAID within 5s" is verifiable. |
| Actual Result | Optional | Populated at execution time — what actually happened. Used for pass/fail determination + defect reproduction. |
| Status | Optional | Not Run / Pass / Fail / Blocked / Skipped. Updated per execution cycle. |
| Severity (if defect) | Optional | Severity of the defect raised, if any. Often distinct from priority. |
| Automation Status | Optional | Automated / Manual / Candidate. Drives automation-investment prioritisation. |
| Notes / Attachments | Optional | Screenshots, logs, edge-case observations. Especially important for exploratory cases. |
Four real test cases across the most common test types. Steal, modify, ship.
Preconditions: User logged in; cart contains 1 item; valid test card on file.
Steps
Expected: Order confirmation page renders with order ID; order appears in /account/orders with status=PAID within 5s; confirmation email sent to user@example.com (webhook delivered).
Preconditions: User logged in; cart contains 1 item; expired test card (exp 01/2020) on file.
Steps
Expected: Decline message "Your card has expired. Please use a different card." rendered inline; user remains on /checkout; no order created in DB; no webhook fired; PaymentAttempt logged with reason=expired_card.
Preconditions: User logged in; cart total = USD 999,999.99 (largest supported); valid high-limit test card.
Steps
Expected: Order created with total=999999.99; Stripe charge.amount = 99999999 (cents); no integer overflow; receipt PDF renders amount correctly formatted.
Preconditions: User logged in with billing country=DE (any EU member state — representative of the EU VAT equivalence class).
Steps
Expected: Tax line item = EUR 19 (19% DE VAT) shown before placing order. Order total = EUR 119. Invoice PDF shows VAT-ID field.
One verb per step. Steps must be reproducible weeks later by a tester who didn't write the case. "Click Pay and verify email" hides two things that can fail independently.
Replace "works correctly" with observable conditions — DB row created, status=X, timestamp within Y seconds, email sent to Z. If you can't verify it deterministically, the test isn't useful for regression.
For every happy-path case, write 2-3 negative + boundary cases. Production bugs come from inputs nobody thought to test — invalid Unicode, daylight-saving edges, zero-quantity orders, expired tokens at 23:59.
Once assigned, never reuse a Test Case ID. Even deprecated cases retain their ID with status=Deprecated. Audit traceability depends on it.
Every case must reference a requirement or acceptance criterion. Orphan test cases either expose a missing requirement (good — file it) or are testing the wrong thing (worse — delete).
A Test Scenario is high-level — "Verify checkout with valid card". A Test Case is the specific, executable form — TC-CO-001 with preconditions, ordered steps, specific test data, and a verifiable expected result. Scenarios feed test-design workshops; test cases get executed.
Detailed enough that a tester who joined the team yesterday can run the case correctly. For automated cases, less verbose (the code is the spec); for manual cases, more verbose. A useful rule: if execution requires reading external docs to know what "click submit" means, the steps are not detailed enough.
No. Exploratory cases, accessibility audits, multi-stakeholder UAT, and one-off regulatory sign-offs are typically manual. Aim to automate the cases that run every release (regression + smoke + critical-path E2E) and accept manual execution for cases that run occasionally or require human judgment.
The RTM maps each requirement to one or more test cases by ID, tracking execution status per cycle. "REQ-CO-007 (decline expired card) → TC-CO-007, last executed 2026-05-14, status=Pass." That mapping is the artifact you hand the auditor when asked to prove coverage.
Whatever the client uses — Xray (Jira native), TestRail, Zephyr Scale, qTest, Polarion (for regulated industries), or simple Markdown/CSV when the team is small. Tool choice doesn't change the template fields; it changes how they're stored and exported.
Talk to a Testriq QA lead — we'll seed a case library for your critical paths and hand it off in your test-management tool of choice.
Get a starter case library