How to Write Test Cases (With a Template and Examples)

Most testing advice treats a test case like paperwork — a box QA has to fill so a spreadsheet looks complete. That framing is why so many test cases are useless. A test case is not documentation; it is a small, repeatable experiment. It says: put the system in this state, do these things, and you should see exactly this. If you see something else, the experiment failed and you have found a bug. Everything good about a test case follows from taking that experiment framing seriously.

Two things flow from it. First, repeatability: the same case run twice, by two different people, on two different days, should reach the same verdict. Second, hand-off: the person who executes a case is often not the person who wrote it, so the case has to carry all the context in the text — not in the author's head. This guide walks through the standard anatomy of a test case (aligned with the ISO/IEC/IEEE 29119 series and ISTQB terminology), gives you a template you can copy, shows two fully worked examples, and names the mistakes that quietly wreck a test suite.

Coverage is the first payoff. When behaviors are written as discrete cases, you can count them, map them to requirements, and see the gaps — the paths nobody is checking. A vague plan that says "test login" hides the fact that nobody ever tried a locked account or an expired session. A list of cases makes the missing ones visible.

Regression protection is the second. The bug you fixed last month comes back; a saved test case is the trap that catches it before your users do. And the third, quietly the most valuable, is hand-off. Testers rotate, contractors leave, and six months from now someone reads your case cold. If it only works when you run it, it isn't a test case — it's a personal ritual. The whole point of the structured fields below is to move the knowledge out of your head and into text that survives you.

Both the ISO/IEC/IEEE 29119 test documentation standard and the ISTQB glossary describe the same core fields. Formats differ across tools, but the semantics are stable. Here is each field, what it means, and the trap to avoid.

Abstract fields only click when you see them filled in. Here are two cases for the same feature — one positive (valid credentials should succeed) and one negative (wrong password should fail gracefully) — written the way you would actually hand them to another tester.

Notice how much is nailed down. The negative case does not just say "login fails" — it specifies how it should fail: the same page, a specific error message, no session cookie, and a cleared password field. That precision is what turns a fuzzy "it errored" into a gradeable outcome. A tester who has never seen this app can run either case and produce the same verdict you would, which is exactly the repeatability and hand-off property we started with.

Good coverage means testing more than the happy path. Three flavors do most of the work:

• Positive cases confirm the system does what it should on valid input and supported paths — the login that succeeds, the form that saves, the payment that clears.
• Negative cases confirm the system fails gracefully on invalid input — wrong password, malformed email, expired token — rejecting the input and showing the right error instead of crashing or silently allowing it.
• Edge cases probe boundaries: the empty field, the maximum-length string, zero, the exact limit value, the leap-second, the duplicate submit. Bugs cluster at boundaries, which is why the 29119-4 test design techniques (like boundary value analysis and equivalence partitioning) exist to derive them systematically rather than by gut feel.

A feature is not really covered until it has all three. Most teams over-invest in positive cases and under-invest in the negative and edge ones — which is precisely where the escaped bugs live.

The unifying theme is that all five mistakes move knowledge out of the written case and into the author's memory — which defeats the entire purpose. A case that only you can execute is not a test case; it is a note to yourself. Write for the stranger who will run it after you have moved teams.

Five habits separate durable test suites from decaying ones:

• One behavior per case. If the title needs "and," split it. Atomic cases give precise failure signals and let you re-run only what broke.
• Atomic and independent. A case must not depend on another case having run first. Set up its own state in preconditions; clean up after itself. Independent cases can run in any order, in parallel, and in isolation.
• Executable by someone else. The acid test: hand it to a colleague who has never seen the feature. If they can run it without asking you a question, it is written well.
• Traceable to acceptance criteria. Every case should answer "which requirement does this verify?" This is where testing meets the spec: cases derive from acceptance criteria, so if you write sharp criteria up front, the cases almost fall out of them. See our guide on writing acceptance criteria that prevent bugs for the front half of this pipeline.
• Keep them alive. A test case is a living asset. When the feature changes, the case changes with it; a suite full of stale cases is worse than no suite, because it manufactures false confidence.

Here is the moment that connects test cases to everything downstream. A case fails — actual result does not match expected — and now a developer has to fix it. The single biggest determinant of how fast that fix happens is the quality of the Actual Result field. And most testers fill it in the weakest possible way: a sentence typed from memory. "Got an error on submit." Which error? What was on the network? What state was the app in? The developer is now debugging your prose instead of the bug.

The fix is to make the Actual Result a captured artifact, not a recollection. Instead of describing what you saw, attach the reproduction itself: a session replay of the exact steps, the console log at the moment it broke, and the network requests that were in flight. That is precisely what BugMojo does — one click on a failed case captures the rrweb DOM replay, console, and network, so the Actual Result field is the real reproduction, complete by construction. The developer opens the ticket and watches the failure happen instead of interrogating you about it. A well-written test case tells you what should happen; a captured failure tells the developer exactly what did — and together they close the loop from spec to fix without anyone reconstructing anything from memory.