Test Case Template & Examples (2026)
A test case is a repeatable check with preconditions, steps, and an expected result. Get a template, a worked example, and the difference from a test plan.
A test case is a specific, repeatable check — given preconditions and a sequence of steps, it states the expected result for one test condition or requirement. This guide gives you a copy-paste template, a worked example, and the exact difference between a test case, a test scenario, and a test plan.
Key takeaways
- A test case is the atomic, executable unit of testing — preconditions, steps, test data, and one expected result.
- A test scenario is a higher-level description of what to test (sometimes called a test script); one scenario expands into several test cases.
- A test plan is the strategy for the whole testing effort; a test case is one specific check inside it.
- The core template fields: ID, title, preconditions, steps, test data, expected result, actual result, status, priority, and linked requirement.
- There's no universal number of test cases per feature — coverage of the paths that matter beats hitting a target count.
A test case is a specific, repeatable check: given preconditions and a sequence of steps, it states the expected result for one test condition or requirement. It’s the atomic, executable unit of testing — the thing a person or a script actually runs, as opposed to a test scenario (a higher-level description of what to test) or a test plan (the strategy for an entire testing effort). This guide gives you a copy-paste test case template, a worked example, and the exact distinctions between the three so you stop conflating them.
What is a test case?
The ISTQB Glossary defines a test case precisely:
A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.
Strip the formality and it comes down to five things: what has to be true before you start (preconditions), what data you feed in, what you do (steps), what should happen (expected result), and what state the system should be left in afterward (postconditions). A test case is deliberately narrow — one objective, one path, one checkable outcome. That’s what makes it repeatable: two people, or a script and a person, running the same test case should reach the same result.
What’s the difference between a test case, a test scenario, and a test plan?
These three get used interchangeably, but they sit at different altitudes — mixing them up is how a “test suite” turns into a pile of vague notes.
The ISTQB Glossary defines a test scenario as:
A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script.
A test scenario is the higher-level “what should we verify” statement — e.g. “a user can complete checkout with a saved card” — without specific inputs or exact steps. A test case makes it executable: real data, concrete steps, one checkable outcome. One scenario commonly expands into several cases (successful payment, declined card, expired card, insufficient funds) across your test pyramid’s unit, integration, and end-to-end layers.
A test plan sits a level above both — the strategy for the whole effort, not one check:
| Artifact | Answers | Example |
|---|---|---|
| Test plan | What are we testing, how, where, and when are we done? | ”Verify the redesigned checkout across supported browsers before release.” |
| Test scenario | What, at a high level, should be verified? | ”A user can complete checkout with a saved card.” |
| Test case | Exact steps and expected result for one specific check | ”Given a saved Visa card and a $50 cart, entering CVV 123 and clicking Pay completes the order and shows a confirmation number.” |
Documenting the overall strategy? That’s a test plan, which contains or references the test cases below.
What should a test case template include?
Cross-referenced against ISTQB’s recommended field set and Atlassian’s community guide to building a Jira test case template, a solid test case template includes:
- Test case ID — a stable identifier so you can reference and trace it (e.g.,
TC-042). - Title / objective — one line stating what this case verifies.
- Preconditions — the state, data, or environment that must exist before you run the steps.
- Test steps — concrete, ordered actions, not descriptions (e.g., “1. Navigate to /login. 2. Enter valid credentials. 3. Click Sign In.”).
- Test data — the specific input values used (account, card number, payload, file).
- Expected result — what should happen if the system behaves correctly, precise enough to be a clear pass/fail.
- Actual result — what actually happened, filled in during execution.
- Status — pass, fail, or blocked.
- Priority — how much it matters if this breaks (critical/high/medium/low).
- Tags / linked requirement — a link back to the requirement, ticket, or user story this case verifies.
Not every case needs full rigor — a quick smoke check doesn’t need what a compliance-critical payment path does — but these fields are what let someone other than the author run, evaluate, and trace the case.
The test case template
Copy this and adapt it to your tool of choice:
# Test Case: [ID] — [Title]
## Objective
What this test case verifies, in one sentence.
## Preconditions
State, data, or environment that must be true before execution.
## Test Data
The specific input values used (accounts, payloads, files, cards).
## Test Steps
1. Step one
2. Step two
3. Step three
## Expected Result
What should happen if the system behaves correctly — stated precisely
enough to be a clear pass/fail.
## Actual Result
What actually happened (filled in during execution).
## Status
Pass / Fail / Blocked
## Priority
Critical / High / Medium / Low
## Tags / Linked Requirement
e.g. JIRA-1234, "checkout-payment"A worked example
For the checkout scenario above, two of the test cases it expands into:
| ID | Title | Preconditions | Steps | Expected Result | Priority |
|---|---|---|---|---|---|
| TC-042 | Successful checkout with a saved Visa card | User is logged in; cart contains one $50 item; a Visa card is already saved | 1. Open checkout. 2. Select the saved Visa card. 3. Enter CVV 123. 4. Click “Place order.” | Order confirmation page loads with a valid order number; confirmation email is queued | Critical |
| TC-043 | Checkout blocked with an expired card | User is logged in; cart contains one $50 item; the saved card’s expiry date has passed | 1. Open checkout. 2. Select the expired card. 3. Click “Place order.” | Order is not placed; an inline error reads “This card has expired” | High |
Both rows share a scenario but cover different conditions — one happy path, one failure — each with its own data and a checkable result.
How do you write a good test case?
- Cover one condition per case. Writing “and also verify” is a sign to split it into a second case.
- State preconditions precisely. “User is logged in” works; “system is set up correctly” doesn’t — anyone should be able to reproduce your starting state.
- Write steps as actions. “Click Place order” is a step; “test the order placement” is a scenario pretending to be a test case.
- Make the expected result checkable. “Works correctly” isn’t verifiable; “order confirmation page loads with a valid order number” is.
- Tag by priority. Priority tags let you pull a fast subset for smoke tests without running the full regression suite.
- Link back to a requirement. An untraceable test case is a maintenance liability the day someone asks why it still exists.
Writing test cases while you build the feature — not after it’s already shipped — is the same shift-left habit that keeps them accurate. And once cases run automatically in CI, their pass rate becomes one of the conditions a quality gate actually checks — a gate is only as meaningful as the cases behind it.
When do you outgrow a spreadsheet?
Spreadsheets are a reasonable place to start — cheap, familiar, fast to edit — but they don’t scale indefinitely. One practitioner on the Ministry of Testing community put it plainly (one person’s experience, not a study): spreadsheets “work fine up to around 100 odd test cases, after that Excel starts to drag you down.” Past that point, teams typically feel it as broken filtering, no link between a test case and its run history, and no visibility into flake or failure trends without manual digging.
That’s the point to move to a dedicated tool that tracks execution history, links cases to requirements and runs, and surfaces pass rate and flake trends automatically. Get started free with Qualflare to organize test cases and runs without outgrowing your tracking the way a spreadsheet eventually does.
Frequently asked questions
What is a test case?
A test case is a specific, repeatable check: given preconditions and steps, it states the expected result for one test condition or requirement — the atomic, executable unit of testing.
What’s the difference between a test case and a test scenario?
A test scenario is the higher-level “what to test” statement, also called a test script. A test case makes it executable: exact preconditions, steps, test data, and one expected result. One scenario typically expands into several test cases.
What’s the difference between a test case and a test plan?
A test plan is the strategy for an entire testing effort — scope, approach, environment, and entry/exit criteria. A test case is one specific check inside it. See our test plan template guide for the plan-level document.
What should a test case template include?
At minimum: ID, title/objective, preconditions, test steps, test data, expected result, actual result, status (pass/fail/blocked), priority, and a link back to the requirement it verifies.
How do you write a good test case?
Cover one condition per case, state preconditions precisely, write steps as concrete actions rather than descriptions, and make the expected result specific and checkable — not “works correctly” but the exact output you expect.
How many test cases do you need for a feature?
There’s no universal number. Coverage of the paths that carry risk — critical journeys, boundary conditions, error states, supported platforms — spread appropriately across your test pyramid matters more than hitting a count. Prioritize by risk and traceability to requirements.
