Test Case Template: Free Excel and CSV With Examples
A test case template is a fixed set of fields every test case fills in the same order: an ID, a title, the preconditions, the steps, and the expected result, plus a few fields for sorting and tracing. The template below has ten fields and comes as an Excel file and a CSV, with six filled examples for a login page.
Download the Excel template (.xlsx) · Download the CSV template
The point of a template is that the next person can run a case without asking the author anything. A case that reads "Login works" fails that test: nobody knows which account, which browser state, or what "works" means. A case with a precondition, exact test data, numbered steps, and an observable expected result passes it, and it can be imported into a test management tool without a cleanup pass.
What fields does a test case template need?
| Field | What goes in it | Example |
|---|---|---|
| ID | A stable reference that never changes or gets reused | LOGIN-003 |
| Title | One line naming the behavior under test | Lock the account after 5 failed attempts |
| Section | Where the case lives in the suite tree, with / for nesting | Authentication/Login |
| Requirement | The requirement or ticket this case verifies | REQ-13 |
| Preconditions | The state the system must be in before step 1 | Account exists; 0 failed attempts recorded |
| Test Data | The exact values the steps use | qa.user@example.com, Wrong#Pass1 |
| Steps | Numbered actions, one per line, in one cell | 1. Open /login 2. Submit the wrong password 5 times |
| Expected Result | What the tester checks, stated so it can be observed | Account locked for 15 minutes; lockout message shown |
| Priority | High, Medium, or Low | High |
| Type | Positive, Negative, or Boundary | Negative |
The first seven fields are the ones a tester needs to run the case. Priority and Type decide which cases run in a smoke pass and which only run in a full regression. Requirement is the field people skip, and the one that answers "which cases do I rerun now that REQ-13 changed?" without reading the whole suite.
Some teams add Status, Actual Result, Executed By, and Date. Those belong to a test run, not to the case, so keep them in the run or in your test management tool. A case with last Tuesday's result baked into it goes stale the moment someone runs it again.
Free and open sourceCasely writes these cases for youAttach a spec and one file of your team's existing test cases in Claude. Casely copies your columns, names the gaps it found in the spec, and exports a single Excel file your tracker imports in one pass.Read the install docsTest case template examples for a login page
The download includes six cases for a login form. Three of them show the patterns that matter most:
Positive case. LOGIN-001, "Log in with a valid email and password." Precondition: the account exists and is active. Steps: open /login, enter the email, enter the password, click Log in. Expected result: the user lands on /dashboard and sees their name in the header. The expected result names a page and something visible on it, so two testers would agree on pass or fail.
Negative case. LOGIN-003, "Lock the account after 5 failed attempts." The precondition says zero failed attempts are recorded, because a leftover attempt from the last run changes the count. The expected result covers the step people forget: after the lockout, the correct password is rejected too.
Boundary case. LOGIN-005, "Accept an email at the 254-character limit." Boundary cases come from the numbers in the requirement. If the spec says 254 characters, the useful cases sit at 254 and 255, not at 20. The equivalence partitioning and boundary value analysis guide covers how to pick them.
How to fill in the template
- Start from the requirement, not the screen. Each acceptance criterion becomes at least one positive case and one negative case. If a criterion cannot produce an expected result, it is not testable yet; send it back before writing cases around a guess. The post on testable acceptance criteria shows what to ask for.
- Write the title as the behavior. "Reject a wrong password" beats "Login test 2." A list of good titles reads like a coverage map.
- Put the state in Preconditions and the values in Test Data. Steps then stay short and reusable, and changing the test account touches one field instead of every step.
- Make each expected result observable. Name the page, the message text, the value, or the record that should exist. "Works correctly" and "as expected" are not results.
- Keep one case per row and one behavior per case. A case that checks login, profile edit, and logout fails for three different reasons, and the failure report cannot say which.
How to import it into TestRail, Qase, Zephyr, or Xray
The template is laid out for import: one header row, one case per row, no merged cells, no blank rows, and the steps in a single cell. Delete the "How to use" sheet if your tool reads every sheet in the file, then map the columns in the import wizard. Section maps to the folder or suite, Steps and Expected Result map to the tool's step fields, and ID maps to the external or reference ID so a second import updates cases instead of duplicating them.
Each tool has its own quirks: how it splits steps, which ID column it matches on, whether priority values have to match its own scale. The post on why a TestRail or Zephyr import fails at row 40 lists the five mistakes that break imports and the shape that survives all four tools.
Where a template falls short
A template makes cases consistent. It does not make them complete. A suite of perfectly formatted cases can still miss the concurrency rule, the timeout, or the empty state, because the template only holds what someone thought to write down. Test coverage comes from test design techniques applied to the requirement, and a template has no field for "what did we forget?"
Spreadsheets also stop scaling around a few hundred cases. Once several people edit the same file, run history matters, or cases need to link to defects written up as proper bug reports, a test management tool earns its cost, and the template becomes the import format instead of the system of record.
What is worth automating
Filling the template from a written requirement is mechanical work: one row per behavior, values pulled from the spec, the same fields every time. That part can be generated. Casely is a free, open-source Claude skill that reads a requirement, proposes a test plan for review, and writes cases in your team's existing columns, this template included. Deciding which behaviors deserve a case, and checking that each expected result matches the requirement, stays a human job.