Test case template
Updated 2026-11-12 · 3 min read
A test case template with the columns teams actually use, an explanation of each, and two filled examples. Download as Excel (.xlsx) or CSV and use it in Google Sheets too.
The Excel file has the header row, two example rows and drop-down lists for Priority and Status. In Google Sheets, choose File, Import, Upload and pick the file. Copy the sheet for each feature or sprint.
What each column is for
| Column | What to write |
|---|---|
| Test case ID | A unique, stable ID, such as LOGIN-001. Never reuse an ID. |
| Module / feature | Where it belongs, such as Login or Cart. Lets you filter. |
| Title | One line saying what is verified: "Login fails with a wrong password". |
| Preconditions | State needed before step 1: "User [email protected] exists and is active". |
| Test steps | Numbered, one action per line, so that someone new can follow it. |
| Test data | The exact inputs, or where to find them. Never write "valid data". |
| Expected result | What must happen, observable and specific. One check per line. |
| Actual result | Filled during execution. |
| Status | Not run, Pass, Fail, Blocked. |
| Priority | High, Medium, Low: how important it is to run. |
| Type | Functional, negative, boundary, UI, security, performance. |
| Linked requirement | Requirement or story ID for traceability. |
| Defect ID | The bug raised if it failed. |
| Executed by / date | Who and when. |
Two filled examples
| ID | Title | Steps | Test data | Expected result |
|---|---|---|---|---|
| LOGIN-001 | Login succeeds with valid credentials | 1. Open /login. 2. Enter email and password. 3. Click Sign in. | Email [email protected], password from the test vault | Dashboard opens and shows "Welcome, Asha" |
| LOGIN-002 | Login fails with a wrong password | 1. Open /login. 2. Enter a valid email and a wrong password. 3. Click Sign in. | Email [email protected], password wrong-pass-1 | Message "Email or password is incorrect"; user stays on /login; no session is created |
Writing good test cases
- One purpose per case. If the title contains "and", consider splitting it.
- Steps that a stranger could follow without asking you.
- Expected results you can check by looking at the screen, response or database.
- Independent: a case should not rely on another case having run first.
- Names that describe behaviour, not pages: "Coupon cannot be applied twice", not "Cart test 7".
Not just manual
The same columns map to automated tests: ID becomes the test name or a tag, steps become the code and expected result becomes the assertion. For ready-made sets, see the login page test cases.
Downloads
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.