Writing test cases is a big part of software testing. Good test cases help you find bugs faster, keep your testing organized, and make it easier for others on your team to understand what you’re doing. Bad test cases, on the other hand, can lead to confusion, wasted time, and missed problems.

In this article, I’ll share what makes a test case useful, how to write clear ones, and what to avoid.

What makes a Test Case “Good”?

A good one:

  • Checks that a specific feature works the way it should
  • Is easy to follow, even for someone new to the project
  • Can be reused and updated when the system changes
  • Gives a clear result: pass or fail

It’s not just about writing steps; it’s about making sure the test helps the team build better software.

What should a Test Case include?

Here are the basic parts of a complete test case:

  • ID or Number: To keep things organized
  • Title: A short description of what you’re testing
  • Preconditions: What needs to be set up before you start
  • Steps: The actions to take, written clearly and in order
  • Expected Result: What should happen 
  • Actual Result: What actually happened when you ran the test
  • Status: Passed, Failed, Blocked, etc.
  • Link to the Requirement or Story: So you know why this test exists

Tips for writing clear and useful Test Cases

1. Be clear and specific

Write steps so that anyone can follow them without guessing.

Bad example:
Click the menu and complete the task.

Better example:
Click the “Settings” icon, then select “Notifications” from the dropdown menu.

2. Focus on one thing at a time

Each test case should check just one thing. If you try to test too much at once, it’s harder to find out what caused a failure.

3. Keep the steps in the right order

Write the steps in the order a real user would do them. Don’t skip anything, even if it seems obvious to you.

4. Test the good and the bad

Test what should work (positive testing), but also test what happens when someone does something wrong (negative testing). For example, entering an invalid email or leaving a field blank.

5. Use a consistent style

Write all test cases the same way. Use the same terms, structure, and formatting. It makes everything easier to read and maintain.

6. Make them easy to update

If the system changes, your test cases should be easy to change too. Avoid writing steps that are tied to small details that change often.

Common mistakes to avoid when writing a Test Case

Even experienced testers make these mistakes sometimes:

  • Writing vague steps like “do the usual” or “test the form”
  • Leaving out the expected result
  • Making test cases too long and complicated
  • Not updating tests after features change
  • Duplicating tests that already exist

Bad Test Case example

Title: Test customer creation
Steps:

  1. Go to customer screen
  2. Add details
  3. Save
    Expected Result: Customer is created

Why it’s bad:

  • It’s too vague. Which screen? What details? What exactly should happen after saving?

Good Test Case example

Title: Create a new customer with valid data

Precondition: User is logged into the ERP system with access to the Sales module

Steps:

  1. Go to “Sales” > “Customers” > “Create New Customer”
  2. Enter “Popescu Ioan” in the “Customer Name” field
  3. Enter “popescu.ioan@email.com” in the “Email” field
  4. Enter “+40747611238” in the “Phone” field
  5. Click “Save”

Expected Result:

  • A new customer record is created
  • A success message appears: “Customer created successfully”
  • The new customer appears in the customer list

Extra tips

  • If your team uses Behavior Driven Development (BDD), you can write tests in “Given-When-Then” format for clarity
  • If possible, work with developers and BAs when writing tests. They can help clarify unclear requirements
  • Use a test case tool like TestRail or Zephyr to organize and track your work

A simple question to ask before you finish

Writing good test cases doesn’t have to be hard. With a bit of structure and attention to detail, you can make your tests much more useful for you and your team.

Before you finish a test case, ask yourself: Could someone else run this and understand exactly what to do? If the answer is yes, you’re on the right track.