Test Case Writing
The single most important skill that gets beginner testers hired. Learn to write test cases that anyone can run — and that always give the same result.
1 The Hook
A Christchurch SaaS startup hired two junior testers on the same day. After two weeks, one was given real projects. The other was let go. The difference? Test cases.
The tester who stayed wrote clear, step-by-step instructions that the senior QA could run without asking questions. The other wrote vague notes like "Check the login works." Works how? With what data? What should happen? Nobody knew.
Writing good test cases is the first skill employers screen for. It shows you can think systematically and communicate clearly — the two foundations of professional QA.
2 The Rule
A test case is a single, atomic, repeatable instruction with a clear expected result.
Atomic means it tests one thing. Repeatable means anyone can follow it and get the same result. Clear means there is no ambiguity about what "pass" looks like.
3 The Analogy
A recipe card.
A good recipe tells you exactly what ingredients to use, what steps to follow, and what the finished dish should look like. A bad recipe says "cook until done." A good test case is the same: it gives exact inputs, exact steps, and an exact expected outcome. No guessing.
4 Watch Me Do It
Every test case has the same five parts. Memorise this structure and use it every time.
- ID A unique code: TC-LOGIN-001. Makes it easy to reference in bug reports and trace back to requirements.
- Title One sentence describing what is being tested. "Valid email and password allow user to log in."
- Preconditions What must be true before you start. "User account exists with email test@example.co.nz and password ValidPass123."
- Steps Numbered, specific actions. "1. Navigate to /login. 2. Enter email. 3. Enter password. 4. Click Sign In button."
- Expected Result Exactly what should happen. "User is redirected to /dashboard. Welcome message displays user's first name."
| Field | Content |
|---|---|
| ID | TC-LOGIN-001 |
| Title | Valid credentials redirect user to dashboard |
| Preconditions | User account exists: email = renter@example.co.nz, password = KiwiRenter99! |
| Steps | 1. Open https://rentals.example.co.nz/login 2. Enter email renter@example.co.nz 3. Enter password KiwiRenter99! 4. Click "Sign In" |
| Expected Result | Page redirects to /dashboard. Header shows "Kia ora, [First Name]". No error messages display. |
Notice how specific the expected result is. Not "login works." Not "user logs in successfully." Those are vague. A good expected result describes exactly what the user sees.
Bad test case vs. good test case
| Bad Test Case | Problem | Good Test Case |
|---|---|---|
| TC-42: Check validation Steps: Check the form validation. | Vague; unclear what to check or how | TC-042: Email field rejects non-email Preconditions: Form page loaded Steps: 1. Enter "abc" in email field 2. Tab away Expected: Error message: "Invalid email format" |
| TC-100: Test checkout Steps: 1. Add item 2. Go to checkout 3. Enter address 4. Pay | Multiple tests in one case; hard to debug failures | Split into 4 cases: TC-100: Add item TC-101: Load checkout TC-102: Validate address TC-103: Process payment |
5 When to Use It / When NOT to Use It
✅ Write a test case when...
- You need to prove a feature works
- You are handing testing to someone else
- You need to rerun the same test later (regression)
- The feature is critical or high-risk
❌ Skip formal test cases when...
- You are doing quick exploratory testing
- The change is trivial (e.g. a typo fix)
- You are time-boxing a 10-minute sanity check
Before you apply this technique, ask:
- Is your test case repeatable, or depends on state that changes each run?
- Have you written clear, unambiguous steps that anyone could follow?
- Are you testing one thing, or multiple features in one case?
- Can you reproduce the exact expected outcome each time?
6 Common Mistakes
🚫 Vague expected results
I used to think: "Login works" is a good expected result.
Actually: "Works" means nothing. Write what the user sees: "Redirects to /dashboard and displays welcome message."
🚫 Testing multiple things at once
I used to think: One test case should cover the whole login flow including password reset.
Actually: One test case = one thing. Login with valid credentials is TC-001. Login with wrong password is TC-002. Password reset is TC-003. Atomic cases make failures easy to pinpoint.
🚫 Missing preconditions
I used to think: Steps alone are enough.
Actually: If the tester doesn't know the test account password, they can't run the test. Preconditions prevent wasted time.
🚫 Writing vague test cases as a substitute for documentation
I used to think: A test case is documentation of what should happen.
Actually: Vague test cases like "TC-42: Check form validation" are not repeatable or understandable. Write explicit steps: "1. Enter 'abc' in email field. 2. Tab away. 3. Observe error message: 'Invalid email format'."
When this technique fails
Test case writing fails when test data changes between runs (e.g., "today's date") or when steps assume knowledge of the system that other testers don't have. Also fails when you write test cases for every possible scenario; you'll have 1,000 cases that nobody maintains. Focus on critical paths and edge cases, not coverage for its own sake.
7 Now You Try
Scenario: You are testing an NZ event booking site. A user should be able to search for events in Wellington. Write a complete test case for the search feature using the five-part structure.
Hint: Think about what search term to use, what results should appear, and what the page should look like.
Suggested test case:
| Field | Content |
|---|---|
| ID | TC-SEARCH-001 |
| Title | Search for "Wellington" returns relevant events |
| Preconditions | User is on the events homepage. At least 3 Wellington events exist in the database. |
| Steps | 1. Click the search box. 2. Type "Wellington". 3. Press Enter or click the Search button. |
| Expected Result | Results page displays at least 3 events with "Wellington" in the title or location. Each result shows event name, date, venue, and a "Book Now" button. No error messages display. |
Tip: Your preconditions and expected result might differ slightly. The key is specificity — no room for interpretation.
🎯 Want hands-on practice with AI feedback?
Try the Test Case Writing Worksheet — fill in the full template for a real NZ scenario, get instant AI critique, and compare with a model answer.
8 Self-Check
Click each question to reveal the answer.
Q1. Why must a test case be "atomic" (test only one thing)?
It makes failures easy to pinpoint. If a test case checks login AND password reset, and it fails, you don't know which part broke.
Q2. What's wrong with the expected result "The feature works as expected"?
It's vague. Different people have different ideas of what "works" means. A good expected result describes exactly what the user sees.
Q3. When is it OK to skip writing a formal test case?
During quick exploratory testing or trivial changes. Formal test cases are for repeatability and handoff. If neither matters, notes are fine.