How to Write Test Cases: Template, Examples and Mistakes

To learn how to write test cases, start with one rule: a good test case lets a stranger run it and reach the same verdict you would. You give it a clear title, the starting conditions, exact steps, the data to use, and one precise expected result. Everything else in this guide is a way to get there faster and with fewer cases.

This guide is for junior and manual testers. You will see the fields every useful test case needs, a worked example in a table, how to turn acceptance criteria into cases, and the mistakes that make cases useless. At the end, you will know when a simple checklist is the better choice.

What a test case is for

A test case is a written check. It says what to do, what to use, and what should happen. It has two jobs.

First, it makes testing repeatable. If you run the case today and a teammate runs it next month, you should both see the same thing. Second, it makes testing reviewable. A developer, a product owner or a new teammate can read it and say "yes, that is what we mean" or "no, that is not the rule".

If you want the formal definition, the test case glossary entry covers it. A test case is also different from a test scenario. A scenario is a broad idea, such as "a user logs in". A test case is one concrete check inside that idea, such as "a user with a valid email and a wrong password sees an error".

The fields of a useful test case

You do not need a heavy tool. A spreadsheet works. What matters is that each case carries the same fields, so anyone can read it without asking you questions.

Here is a template you can copy.

• ID: A short, unique label, such as LOGIN-004. It lets you refer to the case in bug reports and test runs.
• Title: One line that says what is checked and under which condition. "Login fails with a wrong password" beats "Login test 4".
• Preconditions: What must be true before step one. For example, "An active account exists for anna@example.com".
• Steps: Numbered actions, each one small and in order.
• Test data: The exact values to type or select. Do not leave "a valid email" for the runner to guess.
• Expected result: What the system must do or show. This is the part that decides pass or fail.
• Priority (optional): How much it matters if this case fails. High, medium or low is enough.

Some teams add actual result, status, environment and a link to the requirement. Add fields only when someone will really read them. A field nobody reads is just extra typing.

A quick test for each field

Before you save a case, ask four questions.

1. Could someone who has never seen this feature run it?
2. Is there exactly one thing being checked?
3. Is the expected result specific enough that two people would agree on pass or fail?
4. Does the case still make sense if the steps run on a fresh environment?

If any answer is no, fix the case now. It is cheaper than fixing it after a confusing test run.

How to write test cases from acceptance criteria

Acceptance criteria are the best source for new test cases. They are the conditions the team agreed the feature must meet. If you want a refresher, see the acceptance criteria glossary entry.

Take this criterion for a password reset feature:

"A user can request a reset link. The link works once and expires after 30 minutes."

Work through it in four steps.

1. Split it into single rules. Here there are three: a user can request a link, the link works once, and the link expires after 30 minutes.
2. Write the happy path for each rule. Request a link and receive it. Open the link and set a new password.
3. Add the negative and edge cases. Open the link a second time. Open it after 30 minutes. Request a link for an email that has no account.
4. Note anything the criteria leave out. What happens at exactly 30 minutes? What if the user requests two links? These questions are valuable. Ask the team before you guess.

That last step is where testers add the most value. Vague criteria hide bugs. Your questions turn them into rules that can be tested.

A worked example: a coupon code field

Let us write real cases for a checkout feature. The rules are:

• A customer can enter a coupon code on the cart page.
• A valid code takes 10 percent off the item total.
• Codes are not case sensitive.
• An expired or unknown code shows an error and the total stays the same.

Here are five test cases for it.

Look at what this table does well.

• Each case checks one rule. COUP-001 and COUP-002 differ only in the case of the code, so a failure points straight at case sensitivity.
• The test data is exact. Nobody has to invent a code.
• The expected result names the number and the message. "It works" would not let anyone decide pass or fail.
• The preconditions say which codes are active or expired, so the cases do not depend on luck.

You could keep going: a code applied twice, a cart with several items, a code on an empty cart. The next section shows how to decide which of these are worth the time.

Use test design techniques to cut the count

More cases do not mean better testing. Ten well chosen cases beat fifty that all check the same thing. Test design techniques help you choose.

• Equivalence partitioning groups inputs the system treats the same way. You test one value per group. In the coupon example, "any unknown code" is one group, so one unknown code is enough.
• Boundary value analysis tests the edges, where bugs often hide. If a coupon needs a minimum cart value of 20.00, test 19.99, 20.00 and 20.01. The boundary value generator can list these values for you.
• Decision tables help when several conditions combine. For example, "code valid" and "cart over minimum" give four combinations, each with one expected outcome.

Our guide to the test design techniques every QA should know goes deeper on each one, with examples you can use in interviews too.

Common mistakes when writing test cases

These mistakes show up again and again. Each one makes a case harder to run or harder to trust.

1. Vague expected results

"The page loads correctly" is not a result. Correct how? Write what the user sees: the heading, the message, the number, the redirect. If you cannot say what the result is, you do not yet know what you are testing.

2. Steps that bundle several checks

A case that logs in, adds an item, applies a coupon, pays and checks the email is really five cases in one coat. When it fails, nobody knows where. Keep each case focused on one behaviour. Use preconditions to skip the setup.

3. Missing test data

"Enter a valid email" means different things to different people. Write the actual value. If data must be unique, say how to create it.

4. Hidden dependencies

If COUP-003 only passes after COUP-001 has run, the cases are tangled. Each case should work on its own, in any order. Put what it needs into the preconditions.

5. Only happy paths

Real users make typos, lose connection and click twice. A suite with only "it works" cases will miss most real bugs. For every rule, ask what could go wrong.

6. Cases that are never updated

When the feature changes, the cases must change too. An outdated case gives false failures or, worse, false passes. Review your cases whenever the requirements move.

When a checklist beats a test case

Not everything needs the full format. A checklist is a short list of things to verify, without detailed steps or data. It is faster to write and faster to run.

Use a checklist when:

• The steps are obvious to the person running them, such as checking that every page in a menu opens.
• You are doing exploratory or smoke testing and want a quick reminder of what to cover.
• The feature is small or changes often, so detailed cases would be out of date by next week.
• The same experienced tester will run it each time.

Use full test cases when:

• Someone new to the feature must be able to run the check.
• The result must be audited or shown to others, for example in a regulated product.
• The check is complex, with exact data and a precise expected result.
• You plan to automate the check later. A clear manual case is a good specification for an automated test.

Many teams use both. They keep a checklist for broad coverage and full cases for the risky parts.

Talking about test cases in interviews

Interviewers often ask, "How do you write a test case?" or "Write test cases for this feature". A strong answer follows a simple order:

1. Ask about the rules and the users before you start.
2. Name the fields you include: title, preconditions, steps, data and expected result.
3. Give one happy path, then negative and boundary cases.
4. Say how you keep the count small, with partitions and boundaries.

If you want to practise saying this out loud, an AssertHired mock interview lets you answer test design questions and get follow-up questions in text or voice. For a full example of this style of answer, read how to approach testing a login page in an interview.

What to do next

Pick a feature you use every day, such as a search box or a sign up form. Write the rules in plain words, then write five test cases in a table like the one above. Ask a friend to run them without help. Every place they get stuck shows you how to improve the case.

Once your manual cases are clear, you will find that automation gets easier too. Clear steps and clear expected results are what a test script needs. If you are thinking about that move, read about how to transition from manual to automation testing.

Frequently Asked Questions

1. "What should a test case include?"

A test case should include an ID, a title, preconditions, numbered steps, test data and an expected result. Priority is a useful extra. Add other fields only if your team will use them.

2. "How many test cases should I write for one feature?"

There is no fixed number. Write enough to cover each rule, the main failure paths and the boundaries, then stop. Equivalence partitioning and boundary value analysis help you avoid repeating yourself.

3. "What is the difference between a test case and a test scenario?"

A test scenario is a broad situation to test, such as "a user applies a coupon". A test case is one specific check with exact steps, data and an expected result. One scenario usually leads to several test cases.

4. "Should I write test cases in a spreadsheet or a tool?"

Either works. A spreadsheet is fine for small teams and for learning, as long as everyone uses the same columns. A test management tool helps once you need history, reports and links to requirements.

5. "Can I write test cases before the feature is built?"

Yes, and it is often a good idea. Writing cases from the acceptance criteria exposes unclear rules early, while they are still cheap to fix. You can fill in exact messages and values once the design is final.