Test case template and examples

Published 19 October 2026

A test case is one check of one thing the software must do: the starting state, the steps, the data, and the result you expect — written so that anyone who runs it gets the same answer. Below are a template, examples for a payment and a login page, positive and negative test cases, and how to write test cases that find problems instead of just passing.

You need to very tightly specify what you are testing for.

— Someone who used to test a large Java application for a living, on Hacker News, 2009

What goes in a test case

The ISTQB glossary defines a test case as “A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions” (ISTQB glossary, via imbus). In practice, a test case has:

• ID and title: TC-101, “Pay an open invoice by card”.
• Requirement: the requirement or acceptance criterion it checks, by ID.
• Preconditions: what must be true before it starts — signed in, an open invoice exists.
• Test data: the exact account, invoice, card or file to use.
• Steps: numbered actions, one per line.
• Expected result: what you should see, for each step that has one.
• Actual result and status: pass, fail, blocked or not run, with a defect number on a fail.
• Priority: what to run first when time is short.
• Tested by and date.

Test case template

One row per test case. The table copies into Excel or Google Sheets as it is:

For a case with many steps, or a tester new to the system, write it out in full:

TEST CASE TC-[n]
[title]

Requirement:    [FR-n], criterion [n]
Priority:       [high / medium / low]
Preconditions:  [   ]
Test data:      [   ]

1. [action]
   Expected: [result]
2. [action]
   Expected: [result]

Postconditions: [what is true after]
Status:         [pass / fail / blocked /
                not run]
Defect:         [DEF-n]
Tested by:      [name], [date]

Test case example

The customer portal from the other templates. These are the test cases the traceability matrix lists for card payments:

TC-102 written out:

TEST CASE TC-102
Pay with a card the bank declines

Requirement:    FR-014, criterion 2
Priority:       high
Preconditions:  signed in as a finance
                clerk; invoice INV-2041
                is open
Test data:      test card that the
                provider always declines

1. Open INV-2041; choose to pay
   by card.
   Expected: the card form shows
   1,250.00 EUR.
2. Pay with the declining test
   card.
   Expected: "Payment declined"
   and the bank's reason.
3. Open the invoice list.
   Expected: INV-2041 is still
   open; no payment is recorded.

Postconditions: no charge at the
                provider
Status:         pass
Tested by:      tester, 9 May

The same checks, run by the client’s own people before go-live, become the UAT test cases UAT-01 and UAT-02.

Test cases for a login page

The classic example. These follow the sign-in lockout criteria on the acceptance criteria page: five wrong passwords in 15 minutes lock the account for 15 minutes.

TC-202 and TC-204 check rules the criteria imply but do not spell out. If nobody can say what the expected result is, the requirement has a gap: ask, and add the answer to the criteria.

Positive and negative test cases

• Positive test cases check that the software does what it should with valid input: the right password signs you in; an approved card pays the invoice.
• Negative test cases check that it handles invalid input and failures safely: a wrong password, a declined card, an empty field, a bank that does not answer.
• Boundary test cases check the edges, where off-by-one mistakes hide: the fourth and the fifth wrong password; an amount of 0.00, 0.01 and the largest allowed.

If a requirement describes only the positive path, the negative cases are where a tester adds the most: each one is a question the requirement should answer.

How to write test cases

1. Start from the acceptance criteria. Each criterion needs at least one positive and one negative case; most need a boundary case too.
2. One test case, one check. If a case can fail for two different reasons, split it.
3. Name the exact data. “A declined card” is not repeatable; “the provider’s declining test card” is.
4. Give each step that has one its expected result. One commenter, who watched a team move from step-by-step cases to Gherkin descriptions: going from “Step 1: Do X. Expected result: Y. Step 2: Do Z. Expected result: Q” to one sentence “without the expected results being linked to each step” was “strictly worse in just about every way” (Hacker News, 2025).
5. Write expected results someone can see: a message, a status, a number — not “works correctly”.
6. Set a priority. High for what would stop the business or lose money; run those first.
7. Link each case to its requirement, so a change to the requirement shows which cases to update and run again.
8. Have someone else run it once. If they need to ask you anything, the case is missing it.

Test case design techniques help find the cases worth writing: equivalence partitioning (one case per group of inputs that behave the same), boundary values (the edges of each group), decision tables (every combination of rules), and state transitions (locked, unlocked, locked again).

How many test cases?

Enough to cover each acceptance criterion, its failures and its edges — and no more than the team can keep current. More is not the same as better. One commenter worked with “a 10,000 test case spreadsheet of each manual action a QA tester must perform on that product to greenlight any individual change”, and found it “pretty amusing to catch all the bugs in production that their exhaustive spreadsheet totally overlooked” (Hacker News, 2023).

Test case vs test scenario vs test script

A use case gives several scenarios — its main flow and each extension — and each scenario gives one or more test cases. In behaviour-driven development, scenarios are written in Gherkin and run as tests — see the Gherkin examples.

Test cases in Jira and test management tools

Teams keep test cases in a spreadsheet, in a test management tool, or in Jira through a test management app or a custom issue type. Whatever the tool, keep the same fields, and link each test case to the requirement or story it checks — that link is what lets you answer “which tests do we run again?” when a requirement changes.

Test cases and AI

AI tools can draft test cases from acceptance criteria, including negative and boundary cases. They also need watching. One commenter, on leaving a coding agent to work alone:

Otherwise it starts randomly deleting stuff or changing the expected results of test cases so they’ll pass.

— Hacker News, 2025

The expected result comes from the requirement, not from what the software does today. Whoever writes the test cases — a person or a tool — someone who knows the requirement has to check them.

Where Specroot fits

This is the problem Specroot works on: test cases tied to the version of the requirement they check, so that when a requirement changes, the test cases to update and run again are easy to find. Specroot for agencies and consultancies.