1 / 10 · Book 11 · Anatomy of a Test Case · drill: interview Q&A⊞ allnext →Get the book →
1.2The Seven Essential Fields
Every test case, regardless of your tooling (TestRail, Zephyr, Google Sheets, or plain Markdown), should include these fields:
| Field | Purpose | Example |
|---|---|---|
| ID | Unique reference for traceability | TC-LOGIN-004 |
| Title | One-line summary of what is being verified | Verify login fails with expired password |
| Preconditions | State the system must be in before starting | User account exists with password expired 1 day ago |
| Steps | Numbered, atomic actions | 1. Navigate to /login 2. Enter email 3. Enter expired password 4. Click Submit |
| Expected Result | Observable, measurable outcome | Error message "Your password has expired" is displayed; user is not redirected to dashboard |
| Actual Result | Filled during execution | (blank until run) |
| Test Data | Specific values needed | Email: expired@test.com, Password: OldPass123! |
The ID Convention
Use a consistent naming pattern. Common formats:
TC-MODULE-NNN— e.g., TC-LOGIN-004, TC-CART-012FEATURE.SCENARIO.NNN— e.g., AUTH.EXPIRED_PW.001- Auto-incrementing from your test management tool
The format matters less than consistency. Pick one and enforce it across the team.
Title Best Practices
Start with a verb. Answer "what is being verified?" in one line:
- Good: "Verify login fails with expired password"
- Good: "Confirm cart total updates after removing an item"
- Bad: "Login test" (too vague — which aspect of login?)
- Bad: "Test that when a user who has an expired password tries to log in the system shows an error" (too long — this is a description, not a title)
Steps: The Atomic Rule
Each step should describe exactly one user action. If a step contains "and," it should probably be two steps.
BAD:
1. Navigate to the login page, enter credentials, and click Submit
GOOD:
1. Navigate to https://staging.example.com/login
2. Enter email: test@example.com
3. Enter password: Test123!
4. Click the "Sign In" button
Expected Results: Observable and Measurable
The expected result must be something you can see, read, measure, or verify in the UI, database, API response, or logs. Avoid subjective language.
BAD: "The page should look correct"
GOOD: "The dashboard displays 'Welcome, John' in the header and shows 3 notification badges"
BAD: "Login works"
GOOD: "User is redirected to /dashboard. The URL changes to /dashboard. The user's avatar appears in the top-right corner."