What Makes a Good Test Case?

A test case is a structured description of one specific thing to verify. Done well, a test case is a contract: anyone on the team can pick it up, follow the steps, and get the same result. Done badly, it is a liability — vague, brittle, and a magnet for misinterpretation. The difference is mostly about discipline, and the discipline is learnable.

The core qualities

A great test case is:

Specific. It tests one thing, not five. "Verify login flow" is not a test case — it is a test plan. "Login with valid credentials redirects to /dashboard" is a test case.

Repeatable. Anyone running it gets the same result. Same inputs, same steps, same expected outcome. No "click around until it breaks."

Independent. It does not rely on the previous test having run. If you can only run test 17 after running tests 1–16 in a specific order, you have one giant test, not seventeen.

Traceable. It is linked to a requirement, user story, or risk. If you cannot answer "why does this test exist?", consider deleting it.

Atomic. Steps are small enough to follow without thinking. "Click submit and verify the response" is fine; "Submit the form, wait for the email, click the link, complete the new flow, check three things" is too much.

Maintainable. When the feature changes, the test is easy to update. Long-winded prose is hard to maintain; short, structured steps are easy.

A good test case vs a bad one

Bad:

Test the login.

1. Try logging in.
2. Make sure it works.

Good:

Title: Login with valid credentials redirects to dashboard

Preconditions: A user account exists with email qa+test@example.com and password Pass1234!.

Steps:

1. Navigate to https://app.example.com/login.
2. Enter qa+test@example.com in the Email field.
3. Enter Pass1234! in the Password field.
4. Click the Sign In button.

Expected result: Within 2 seconds, the URL changes to /dashboard and the user's name appears in the top-right header.

Linked requirement: US-217 (User can sign in with email and password).

The good case is longer because it earns it. Anyone — a new joiner, a contractor, a developer covering for QA — can run it and report a result with confidence.

Common test case smells

A few patterns mark cases that need work:

• "Verify it works correctly." Correctly means what? If you cannot specify the expected result in one sentence, the case is not yet finished.
• No preconditions. The test depends on test data that is never specified, so it works on the author's machine and fails everywhere else.
• One huge case covering ten things. Splitting into smaller cases reveals which specific thing failed and makes parallel execution possible.
• "Click around the page." Exploratory work belongs in a charter, not a test case. Test cases are deterministic.
• Hidden expectations. "Expected: looks right." Right by whose definition? Reference the design or spec.
• Stale references. A test that points at a removed feature or a renamed page is dead weight. Delete it.

Manual cases vs automated cases

Manual test cases are written for a human to follow; automated test cases are written as code. The principles are the same — specific, repeatable, independent, atomic — but the artefact is different. A well-written manual case is often the basis for an automated one: when you decide to automate it, the steps and expected results translate directly.

In a healthy team, manual cases serve three purposes:

1. Exploratory checklists for things that cannot easily be automated (visual checks, UX flows).
2. Onboarding documentation for new testers learning the product.
3. Stepping stones to automation — what gets manual today gets automated tomorrow.

Treating manual cases as second-class citizens is a mistake; treating them as the only source of truth is also a mistake.

How long should a test case be?

Long enough to be unambiguous, short enough to follow without re-reading. A typical good case is 5–10 lines. If it is longer than 15 lines, ask whether you really have one case or three. If it is shorter than 3 lines, ask whether you have left out preconditions or expected results.

What you should walk away with

A good test case is specific, repeatable, independent, traceable, atomic, and maintainable. The next lesson covers the actual structure that makes those qualities easy to apply: test case templates and formats.