How to Write Good Test Cases

Structure, techniques and examples for writing clear, maintainable test cases.

Anatomy of a test case

Every test case answers four questions: what is being tested, what data and setup are needed, what steps to run, and what result proves success or failure.

ID — stable identifier such as TC-LOGIN-001.
Title — a one-line summary of the behavior under test.
Preconditions — state, data and permissions required before execution.
Test data — the specific inputs the steps use.
Steps — ordered, numbered, unambiguous actions.
Expected result — the observable outcome that marks a pass.

Writing clear steps

Each step should contain one action and name a concrete destination. "Enter a valid email" is weak; "Enter admin@example.com into the Email field" leaves no room for interpretation.

The expected result should describe what the user sees or what the system returns, not how the tester feels about it. Vague expected results like "should work" produce disputed test outcomes.

Positive, negative and boundary scenarios

Positive cases verify valid inputs succeed. Negative cases verify invalid inputs are rejected with a clear error. Boundary cases probe the edges of a field's rules.

For a password field of 8 to 32 characters, test exactly 8, exactly 32, 7, 33, and an empty value. These boundary values catch the off-by-one mistakes developers make more often than mid-range values do.

Test case vs test scenario

A test scenario is a high-level behavior statement such as "user can reset a forgotten password." A test case is one concrete, executable checklist derived from that scenario.

Scenarios help you design coverage; test cases execute it. One scenario usually expands into several test cases covering the happy path, validation failures and canceled flows.

Organizing and reusing cases

Organize cases by feature, module or user story so they are easy to find and map back to requirements. Reuse setup-heavy cases through parameters rather than duplicating them.

Keep cases independent where possible. A failure in one should not cascade into meaningless failures across dozens of others.

Common mistakes

Most bad test cases share the same flaws: steps too vague to reproduce, multiple assertions in one step, expected results that are missing, and dependencies on external systems without defined mocks.

Review cases before execution. If you cannot hand the case to a new teammate and have them run it without asking questions, the case is not done.

A good and a bad example

Poor: "Check the login." Good: "Precondition: user account active (user@example.com / Password1!). Open https://app.example.com/login, enter the credentials, verify dashboard appears within 5 seconds."

The good version is repeatable by anyone, states its test data and defines an observable outcome. That is the difference between a note and a test case.

Related tools: Generate varied inputs with the Random Data Generator and shape test payloads in the JSON Formatter. Pair this guide with Bug Reporting for the full loop.