How to Write Test Cases: Examples, Template, and Best Practices

What Is a Test Case?

A test case is a single, repeatable check that verifies one specific behavior of your software: the conditions to start from, the steps to take, and the result you expect to see. If the actual result matches the expected result, the test case passes; if it doesn't, you've found a defect (or a test case that needs updating).

Test cases are the smallest unit of test case management. They're grouped into test suites, selected into test plans, and executed in test runs — so the quality of everything downstream depends on how well each individual case is written.

The Anatomy of a Good Test Case

Every team adds its own fields, but nearly every well-written test case has these:

How to Write a Test Case, Step by Step

1. Start from a requirement, not from the UI

Read the user story, acceptance criteria, or spec first and list the behaviors it promises. Each behavior — including each failure mode the requirement mentions — becomes one or more test cases. Starting from the screen instead tends to produce cases that test what was built rather than what was asked for.

2. Give each test case one objective

A test case that checks login, profile editing, and logout in one pass is three test cases. When it fails you won't know which behavior broke, and you can't run just the part you need. One objective per case keeps results meaningful.

3. Write the title as an outcome

"Login – valid" tells a reviewer almost nothing. "Login succeeds with valid email and password" tells them exactly what's covered, and makes gaps obvious when you scan a suite.

4. Make preconditions explicit

Anything a tester has to know or set up before step 1 — a specific user role, a feature flag, seeded data, a browser — belongs in preconditions. Hidden preconditions are the most common reason two testers get different results from the same case.

5. Write steps as single, concrete actions

Use imperative verbs ("Click Sign in", "Enter the email from test data") and one action per step. Avoid "verify everything looks right" — if something needs checking mid-flow, give that step its own expected result.

6. Make the expected result observable

"It works" isn't an expected result. "The dashboard loads and the header shows the user's first name" is. A good expected result is something two different testers would independently agree passed or failed.

7. Set priority and link the requirement

Priority tells your team what to run when a release is squeezed. Linking the case to its requirement or Jira issue is what makes coverage measurable: when the story changes, you can find every case that needs a second look.

8. Have someone else review it

The best test of a test case is whether someone who didn't write it can execute it without asking a question. A quick peer review catches ambiguous steps and missing preconditions before they cost a failed run.

Test Case Examples

Here's a positive and a negative test case for the same login feature, written to the standard above:

TC-142  Login succeeds with valid email and password
Priority:       Critical
Preconditions:  Verified account exists for qa+login@example.com
Steps:
  1. Go to /login
  2. Enter qa+login@example.com in Email
  3. Enter Correct#Pass1 in Password
  4. Click "Sign in"
Expected:       Dashboard loads; header shows "Hi, QA"

TC-143  Login is rejected with a wrong password
Priority:       High
Preconditions:  Verified account exists for qa+login@example.com
Steps:
  1. Go to /login
  2. Enter qa+login@example.com in Email
  3. Enter Wrong#Pass9 in Password
  4. Click "Sign in"
Expected:       Stays on /login; shows "Email or password is incorrect";
                password field is cleared; no session cookie is set

Notice the negative case checks more than the error message — it also verifies nothing leaked (no session was created). Negative and edge cases are where most real bugs live, so budget as much time for them as for the happy path.

A Test Case Template You Can Copy

This CSV uses the same column headers TestKit's bulk import reads, so you can start in a spreadsheet today and import it later without reformatting. Put numbered steps in the description column.

title,description,preconditions,expected_result,priority,status,tags
"Login succeeds with valid email and password","1. Go to /login
2. Enter valid email
3. Enter valid password
4. Click Sign in","Verified account exists","Dashboard loads; header shows user's first name",critical,active,"auth,smoke"
"Login is rejected with a wrong password","1. Go to /login
2. Enter valid email
3. Enter wrong password
4. Click Sign in","Verified account exists","Error shown; no session created",high,active,"auth,negative"

For a deeper look at running test cases in a spreadsheet — and the point where it stops working — see our Excel test case template guide.

Test Case Best Practices

• Write for a new team member. If it requires tribal knowledge, it isn't finished.
• Keep cases independent. A case shouldn't depend on another case having run first — use preconditions instead.
• Reuse shared setup. If ten cases start with the same five login steps, write those steps once as a shared step group rather than copy-pasting them ten times.
• Cover boundaries. Minimum, maximum, just-over, empty, and invalid inputs catch more bugs than the "typical" value.
• Retire stale cases. Mark cases for removed features as deprecated instead of letting them fail forever or silently get skipped.
• Version your changes. When a case changes, you should be able to see what changed, when, and who changed it.

Common Mistakes to Avoid

• Vague expected results ("page works correctly").
• Multiple objectives crammed into one case.
• Hard-coded data that goes stale (a specific order ID that gets deleted next week).
• Steps that describe what the tester *sees* instead of what they *do*.
• No link back to a requirement, so coverage can't be measured.

Writing Test Cases Faster With AI

AI can now turn a user story into a first draft of test cases in seconds — including negative and edge cases people tend to skip. The draft still needs a human review against the requirement, but starting from a draft is much faster than starting from a blank page. TestKit's AI test case generation works from a user story or a linked Jira issue and drops the drafts straight into your suite for review.

Frequently Asked Questions