tldr: A test case template is a fixed format for writing test cases so every one captures the same fields: ID, title, preconditions, steps, test data, expected result, actual result, status, and priority. Copy the table below and you have a working one.
What is a test case?
A test case is a documented set of preconditions, steps, inputs, and expected results that verifies one specific behavior of an application. It is the smallest executable unit of a test plan. The template matters because cases get written by many people over years, and the fixed format is what keeps case number 400 as complete as case number 4.
The template
| Field | What goes in it |
|---|---|
| Test case ID | Unique, prefixed by area: CHK-012 for checkout |
| Title | One line stating what is verified |
| Preconditions | State required before step 1: logged in, cart has items |
| Test steps | Numbered actions, one action per step |
| Test data | Exact inputs: emails, card numbers, coupon codes |
| Expected result | What should happen, specific enough to judge pass or fail |
| Actual result | What did happen, filled during execution |
| Status | Pass, fail, blocked, or skipped |
| Priority | How urgent this case is when time runs short |
Some teams add environment, related requirement ID, and author. Add fields only when someone reads them. Every unused column makes the next case slower to write.
The same template, with both examples below filled in, is also a plain CSV that imports into Excel, Sheets, or any test management tool.
Two filled examples: positive and negative
The positive case proves the feature works:
| Field | Value |
|---|---|
| Test case ID | AUTH-002 |
| Title | Login succeeds with valid credentials |
| Preconditions | Account maya@example.com exists and is verified |
| Test steps | 1. Open the login page. 2. Enter the email. 3. Enter the valid password. 4. Click Sign in. |
| Test data | Email maya@example.com, password Correct-Horse-9 |
| Expected result | User lands on the dashboard. A session is created. The last-login timestamp updates. |
| Actual result | As expected |
| Status | Pass |
| Priority | High |
The negative sibling proves it fails safely:
| Field | Value |
|---|---|
| Test case ID | AUTH-003 |
| Title | Login rejects a wrong password with a clear error |
| Preconditions | Account maya@example.com exists and is verified |
| Test steps | 1. Open the login page. 2. Enter the email. 3. Enter WrongPass1!. 4. Click Sign in. |
| Test data | Email maya@example.com, password WrongPass1! |
| Expected result | Error reads "Incorrect email or password." No session is created. The account is not locked after one attempt. |
| Actual result | As expected |
| Status | Pass |
| Priority | High |
Both expected results carry three assertions, and each is checkable. "Login works" or "login fails" would be too vague to judge, and vague expected results are the most common defect in test case writing.
How to write a test case
- Steps a new hire could follow without asking anyone anything
- Exact test data, never "enter a valid email"
- One behavior per case, so a failure points at one thing
- An expected result someone could dispute, which means it is specific
The single-behavior rule is the one teams break most. A case that checks login, profile update, and logout in one pass saves writing time and costs it all back the first time it fails and nobody knows which third broke.
Cases inherit their inputs from test design: techniques like boundary value analysis decide which values earn a row in the test data field.
Test case, test scenario, test script, test suite
A test scenario is the one-line parent: "a user cannot log in with wrong credentials." The cases above are two of its children, carrying steps and data. A test script is a case written out for a non-engineer to execute step by step, most common in UAT. A suite groups related cases for a run; the test suite vs test case entry covers that layer. And a test plan is a different artifact altogether: the strategy document for a release, not the row format for a single check.
Written cases also feed automation. A case with exact steps, data, and expected results translates directly into an automated check, which is why a sloppy template quietly becomes a sloppy suite. In Bug0's model the forward-deployed engineer does that translation, turning planned coverage into tests the engine then runs and maintains.
FAQs
What is a test case in software testing?
The smallest executable unit of a test plan: preconditions, steps, inputs, and one expected outcome, written so anyone can run it and judge pass or fail.
How many steps should a test case have?
Most good cases run three to eight steps. Past ten, split it: either the case is checking more than one behavior or the preconditions are doing too little work.
Should test cases live in a spreadsheet or a tool?
Spreadsheets work until cases need execution history, links to bugs, and shared ownership. Teams usually outgrow them around a few hundred cases and move to a test management tool.
