Test Case Template With Examples

A test case is one scripted check with a known right answer, and it needs eight fields: an ID, a title that names the behavior, the preconditions, numbered steps with exact test data, the expected result, the actual result, a status, and a link to the requirement it checks. Expected is written before the test is run, from the requirement, never from what the software happens to do. Below is a template to copy, a spreadsheet layout, six examples, and how to get from acceptance criteria and AI drafts to test cases a person can trust.

A test case is narrower than the documents around it. A QA checklist lists what to look at across a whole release; a bug bash is a session of unscripted exploring; the conditions a feature must meet are its acceptance criteria. A test case turns one of those conditions into steps anyone can repeat and get the same answer.

The fields

• ID. Short and stable, such as TC-LOGIN-003. It is how a bug report, a spreadsheet row and a conversation refer to the same check.
• Title. The behavior under test, as a sentence: “Wrong password shows a generic error”. Not “Login test 3”.
• Preconditions. What must be true before step 1: the account, its role, the data that exists, the environment and build.
• Steps. Numbered actions with the exact values typed or chosen. One action per step.
• Expected result. What a person or a caller can observe when it works: a message, a page, a status code. Written before running the test.
• Actual result. What happened, filled in when the test is run. Exact text for any error.
• Status. Not run, Pass, Fail or Blocked, with the date and who ran it.
• Requirement. The story, task or acceptance criterion this case checks, so a failure leads back to what was promised and a changed requirement leads to the cases that need rewriting.

Optional fields earn their place on larger suites: priority, test data kept apart from the steps, environment, and whether the case is automated.

The template

ID:            TC-<AREA>-<NNN>
Title:         <behavior under test, as a sentence>
Requirement:   <story, task ref or acceptance criterion>
Preconditions: <account and role> · <data that exists>
               <environment and build>
Test data:     <exact values used>

Steps:
  1. <action>
  2. <action, with the exact value>
  3. <action>

Expected:      <what can be observed when it works>
Actual:        <what happened; exact error text>
Status:        Not run / Pass / Fail / Blocked
Run by / on:   <name>, <date>
Notes:         <bug ref if it failed; anything odd>

As a spreadsheet

For a test case template in Excel or Google Sheets, make each field a column and each case a row: ID, Title, Requirement, Preconditions, Steps, Test data, Expected, Actual, Status, Run by, Date, Bug. Keep the steps in one cell with line breaks so a row stays one case. Make Status a drop-down so it cannot drift into “passed?” and “ok”: Microsoft’s guide to creating a drop-down list↗ (opens in a new tab) does it with Data Validation, Allow: List, and a source of Not run, Pass, Fail, Blocked. Then filter on Fail and Blocked to see what needs attention.

How to write test cases that work

• One behavior per case. A case that checks sign-in, the dashboard and sign-out fails without saying which.
• Steps a stranger can follow. If it needs the person who wrote it, it is a note, not a test case.
• Exact data. “Enter an email” gives a different test every run; “Enter tester01@example.com” does not.
• An observable expected result. “Works correctly” cannot fail; “Shows Order confirmed and an order number” can.
• Independent cases. Each one sets up its own preconditions, so they can be run in any order.
• Negative cases on purpose. For every rule, at least one case that breaks it: wrong input, missing permission, the value just past the limit.

Six test case examples

ID:            TC-LOGIN-001
Title:         A registered user signs in with the right password
Preconditions: Account tester01@example.com exists, not locked
Steps:         1. Open /signin
               2. Enter tester01@example.com and the account's password
               3. Press Sign in
Expected:      The dashboard opens and shows "Signed in as tester01"

ID:            TC-LOGIN-003
Title:         A wrong password shows a generic error
Preconditions: Account tester01@example.com exists
Steps:         1. Open /signin
               2. Enter tester01@example.com and "wrong-password-1"
               3. Press Sign in
Expected:      "Email or password is incorrect". The message is the
               same for an address with no account (TC-LOGIN-004).
               The failed attempt is counted toward the lockout limit.

Lockout limits are worth their own cases, and a standard helps you pick the number. NIST’s Digital Identity Guidelines, SP 800-63B↗ (opens in a new tab) say a verifier shall limit consecutive failed attempts on one account to no more than 100, so a case that proves the limit exists, and one that proves the right password still works after a few wrong ones, belong in the suite.

ID:            TC-CHECKOUT-007
Title:         A declined card keeps the cart and explains why
Preconditions: Test mode. Cart has 2 items. Signed in as tester02
Test data:     Card 4000 0000 0000 0002, any future date, any CVC
Steps:         1. Open /checkout
               2. Enter the card, press Pay
Expected:      "Your card was declined." The cart still has 2 items.
               No order is created. Paying again with
               4242 4242 4242 4242 succeeds (TC-CHECKOUT-001).

Never test with real card numbers. Payment providers publish test numbers for this; Stripe’s testing docs↗ (opens in a new tab), for example, list 4242 4242 4242 4242 as a card that succeeds and 4000 0000 0000 0002 as a generic decline, for use with test keys in a sandbox only.

ID:            TC-API-012
Title:         GET /v1/orders without a token is refused with 401
Preconditions: Staging API, build 2026.09.4
Steps:         curl -i https://staging.example.com/v1/orders
Expected:      Status 401. A WWW-Authenticate header is present.
               The body contains no order data.
Related:       TC-API-013: a valid token for another account gets 403
               or 404 for someone else's order, never the order.

API cases can quote the standard for their expected result. RFC 9110↗ (opens in a new tab), which defines HTTP semantics, says a 401 means the request lacks valid authentication credentials and that the server must send a WWW-Authenticate header with it, while 403 means the server understood the request but refuses to fulfill it.

ID:            TC-A11Y-002
Title:         The sign-up form can be completed with a keyboard alone
Preconditions: Chrome, no mouse or trackpad used
Steps:         1. Open /signup, press Tab to reach the first field
               2. Fill every field and the checkbox using Tab,
                  Shift+Tab, Space and Enter only
               3. Submit with Enter
Expected:      Every field and the button can be reached in a
               sensible order; the focus outline is always visible;
               the account is created.

That case checks two success criteria in WCAG 2.2↗ (opens in a new tab): 2.1.1 Keyboard, at Level A, and 2.4.7 Focus Visible, at Level AA. Name the criterion in the Requirement field and a failure explains itself.

ID:            TC-UPLOAD-005
Title:         A file over the 20 MB limit is refused with a message
Preconditions: Signed in; an open job with no attachments
Test data:     photo-24mb.jpg (24 MB)
Steps:         1. Open the job, press Attach
               2. Choose photo-24mb.jpg
Expected:      "Files must be 20 MB or smaller." Nothing is uploaded.
               The job still has no attachments. The app stays open.

From acceptance criteria to test cases

Acceptance criteria say what must be true; test cases prove it. Each criterion becomes at least one passing case, plus a case at each boundary and a case that breaks the rule. A Given/When/Then scenario maps directly: Given becomes the preconditions, When the steps, Then the expected result. How to write the criteria themselves, and twenty examples, are in acceptance criteria examples.

Criterion: A discount code expires at midnight on its end date.

TC-DISC-001  Code used at 11:59 p.m. on the end date: accepted
TC-DISC-002  Code used at 12:00 a.m. the next day: refused with
             "This code has expired", not "invalid code"
TC-DISC-003  Code with no end date: accepted

AI-drafted test cases, reviewed by a person

An AI assistant is quick at turning a requirement into a first set of cases, especially the negative and boundary cases people forget. Give it the requirement and the template, not the code: an assistant that reads the implementation writes expected results that describe what the code does, including its bugs.

Write test cases for the requirement below, using the template below.

- One behavior per case. Exact test data. Observable expected results.
- For every rule: one passing case, one at each boundary, one that
  breaks it.
- Take expected results from the requirement only. Where it does not
  say what should happen, list the question instead of guessing.
- Use example.com addresses and payment test numbers, never real data.

Requirement:
<paste>

Template:
<paste>

• Check each expected result against the requirement. This is the review that matters; the rest is tidying.
• Read the questions list. Every question is a gap in the requirement, and the answer belongs in the requirement, not only in the test.
• Cut duplicates and cases that test the framework rather than your feature.
• Look for missing cases: permissions, empty states, the second time an action runs, slow or failed connections.
• Run a few by hand before trusting the set. A case that cannot be followed will show itself on the first run.

Failed cases become bugs

A failed test case is most of a bug report already: the steps, the expected result and the actual result. Add the environment, evidence and severity from the bug report template, put the case ID in the report, and put the bug ref back in the case’s Notes. When the bug is fixed, run the case again; the case passing is how everyone knows the fix worked.

On a fenbs board, each failed case becomes a task of kind bug with a ref such as BUG-091, the case ID and steps in its note, and a priority from 1 to 10, 1 the most urgent. After a test run with several failures, Add many takes a pasted list, one task per line, and a line starting bug: is filed as a bug. The feature being tested records the run in its Testing section: Failed, Partly tested or Tested, with notes on what was run and what was not. fenbs does not store test cases or run them; keep the suite in a spreadsheet or a test tool, and use the board for the work the failures create.