A test case template with a worked example
A good test case can be run by someone who didn't write it, and its result means the same thing every time. Here is a template that does that, with a filled-in example you can copy.
The fields that matter
Most templates have too many columns. These eight are enough for nearly every services project:
| Field | What goes in it |
|---|---|
| ID | A short, stable key, such as PAY-T12. Never reuse one. |
| Title | What is being checked, in plain words: "Card payment succeeds with a valid OTP". |
| Story | The story or requirement it covers, such as PAY-112. |
| Preconditions | What must be true before step 1: test data, user role, feature flags. |
| Steps | Numbered actions, one action per step. |
| Expected result | What should happen after each step, or at least after the last one. |
| Priority | Critical, high, medium or low. It decides what runs when time is short. |
| Suite | The module or area, so you can build a run for one part of the app. |
Leave the result out of the test case itself. A test case is the instructions; each run records its own result. Mixing the two is how one sheet turns into ten copies.
A filled-in example
ID: PAY-T12 Title: Card payment succeeds with a valid OTP Story: PAY-112, "Pay a bill with a debit card" Priority: Critical Suite: Payments › Cards
Preconditions
- A test customer with a saved Visa debit card and a bill of ₹1,250 due.
- The payment gateway is in sandbox mode.
Steps
| # | Action | Expected result |
|---|---|---|
| 1 | Open the bill and choose Pay now | The payment page shows ₹1,250 and the saved card |
| 2 | Choose the saved card and enter CVV 123 | The OTP screen opens |
| 3 | Enter the sandbox OTP 111000 | A success page shows a payment reference |
| 4 | Open Payment history | The bill shows as paid with today's date and the same reference |
Writing rules that save time later
- One behaviour per test case. "Payment succeeds" and "payment fails with a wrong OTP" are two cases.
- Exact test data. Write the amount, card and OTP, not "valid details".
- Observable expected results. "Shows a payment reference" can be checked. "Works correctly" can't.
- No hidden steps. If step 2 needs a logged-in user, say so in the preconditions.
- Link every case to a story. It's the only way to answer "what covers this requirement?" quickly.
- Write from the acceptance criteria. Each criterion should have at least one test case.
Common mistakes
| Mistake | Better |
|---|---|
| Steps like "Test the payment flow" | One action per step, with its expected result |
| Recording pass or fail in the test case | Record results in a test run, one per release |
| Copying the sheet each release | Keep one set of cases and create a new run |
| Cases with no link to a story | Add the story key when you write the case |
| Only happy paths | Add the main failure for each critical story |
Using the template in a tool
The same fields work in a spreadsheet or a test management tool. In NaatOps, each test case has a title, preconditions, numbered steps with expected results, a priority and a suite, and links to the stories it covers. Cases can be drafted from a story's acceptance criteria, and runs record results separately for each release. If your cases are in Excel today, NaatOps imports them as they are.
See how to move test cases out of Excel, see the Excel import, or start free.
Stories, tests and API checks in one place
Free for up to 10 users. Team and Delivery start with a free trial, no card needed.