How to write effective test cases: anatomy, reliability and a worked login example

How do you write a good test case?#

Write a good test case by turning one test condition into one atomic check with stated preconditions, exact test data, numbered steps and a single expected result.

The ISTQB glossary, as it stood on 8 October 2026, defines a test case as "A set of preconditions, inputs, actions (where applicable), expected results and postconditions", developed from test conditions. Also, a test condition is, in the same glossary, "A testable aspect of a component or system". So the condition is the thing you want to know, and the case is how you find out.

In practice, that definition already names the five parts a reviewer looks for. Preconditions say what must be true before you start. Inputs are the exact data, not "a valid email". Actions are the steps. Then the expected result says what should happen, and postconditions say what state the system is left in. If any one is missing, a second tester has to guess. And a guess is where two runs of the same case start to disagree.

What do effective test cases save a team?#

For a login of 6 to 15 characters, the ISTQB boundary value white paper (October 2025) leads to 5 test cases, or 10 with 3-value analysis.

So effective test cases turn "test the edge cases" into a fixed count that a reviewer can check line by line. That is the real saving. Without a method, two testers given the same login field write different lists. Then the team cannot say which list is complete. With a method, the list follows from the requirement. As a result, a missing case shows up as a gap, not as a matter of taste.

The trade is plain, because rigour costs cases. So the team picks the level that matches the risk of the field. A login on a public sign-up form deserves the edges. A free-text comment box may only need one case per group. Either way, the count is a decision written down, not a hunch.

Why is test design the core skill behind every test case?#

The ISTQB Foundation syllabus (v4.0.1, September 2024) gives Test Analysis and Design 390 minutes of instruction, more than any other chapter.

In that syllabus, dated 15 September 2024, the next largest chapter is Managing the Test Activities at 335 minutes. By contrast, Test Tools gets 20. So the weighting says where the craft sits. Writing the case down is the last step, and deciding what to test and which inputs prove it is the work.

This is also why test case design is a staple of manual testing interview questions. A question such as "how would you test this login field" is a test design question in disguise. So a tester who can name the conditions and pick the edges answers it in a minute. Meanwhile, a tester who lists inputs from memory runs out of ideas and cannot say when the list is done.

What fields does a test case template need?#

A test case template needs an ID, a title, the test condition it covers, preconditions, test data, steps, one expected result, postconditions and a priority.

In fact, every field maps to a part of the ISTQB definition or to traceability. For the wider shape, ISO published ISO/IEC/IEEE 29119-3:2021 in October 2021. That standard "specifies software test documentation templates" that any organisation can adapt. So use the table below as a starting point and rename fields to match your tool.

These are the test case attributes most tools ask for. Here the required fields are the ones a stranger needs to rerun the case without asking you a question. As a result, a reviewer bounces an empty precondition or test data field first. Those two are what make reruns disagree.

What makes a test case reliable enough for someone else to run?#

A reliable test case is atomic, repeatable, traceable to one requirement and ends in an expected result that two testers would judge the same way.

First, atomic means one condition per case. For cases built from a user story, the ISTQB Foundation syllabus (September 2024) says "no two test cases should describe the same characteristics" of the story. Second, repeatable means fixed data and a stated setup, so the case gives the same result on Monday and Friday. Then traceable means a link to the requirement, so a changed requirement tells you which cases to revisit. Finally, unambiguous means the expected result is an observable fact, not "works fine".

Here is a vague login case and its rewrite.

Illustrative rewrite of one case; the input and result come from the ISTQB white paper's login example.

The rewrite does not add effort so much as it removes guessing. In particular, "a valid login" could mean any of ten lengths, and each tester would pick a different one.

1. Title

   Before: Check login works. After: Login of exactly 6 characters is accepted.

2. Data

   Before: A valid login. After: John99.

3. Steps

   Before: Enter login and test it. After: 1. Enter John99 in the login field. 2. Fill the other required fields with valid values. 3. Select Register.

4. Expected result

   Before: Works fine. After: Login accepted.

What do positive, negative and boundary test cases for a login form look like?#

In the ISTQB boundary value white paper (October 2025), a valid login has 6 to 15 characters, so John99 passes and an empty login fails.

The paper's requirement reads "A valid login has at least 6 and at most 15 characters." So from that one line come three kinds of case. A positive case confirms the system accepts what it should. A negative case confirms it rejects what it should. Then a boundary case sits exactly on an edge, where a wrong comparison sign would change the answer. The ISTQB syllabus (September 2024) notes that "Typically, the first test cases are positive", so write the positive one first.

Source: ISTQB, Boundary Value Analysis white paper, October 2025, Table 2.

Each row is a full case once you add the template fields. For example, TC-R-min needs the same precondition as TC-P-min, an open registration form, and its own expected result. Because the data differs, the two never share a row. So a failure in one tells you exactly which edge broke.

How do equivalence partitioning and boundary value analysis decide which cases to write?#

Equivalence partitioning takes one value per partition, and boundary value analysis adds the edges, where the ISTQB syllabus (v4.0.1, September 2024) says defects cluster.

Equivalence partitioning splits the input into groups the system should treat the same way. The syllabus says "one test for each partition is sufficient." In the ISTQB white paper's login example (October 2025), the lengths fall into three partitions. There, 0 to 5 is too short, 6 to 15 is valid and 16 or more is too long. So three cases cover the groups.

Next, boundary value analysis, or BVA, tests the edges of each group. The same 2024 syllabus says "developers are more likely to make errors with these boundary values". With 2-value BVA, each edge and its nearest neighbour across the line are tested. So for the login, the white paper lists the lengths 0, 5, 6, 15 and 16, which is 5 cases. With 3-value BVA, each edge and both neighbours are tested. Then the white paper's set grows to 10 lengths: 0, 1, 4, 5, 6, 7, 14, 15, 16 and 17.

In short, the list comes out of the requirement. If the limits change, the cases move with them. So the team does not have to remember to test "one more than the maximum".

What does one complete test case look like written as data?#

One complete test case fits in about twenty lines of YAML: an ID and condition, preconditions, the input, the steps, one expected result and a postcondition.

YAML is a plain text format for structured data that most test tools and scripting languages can read. Because an empty key is easy to spot, writing a case this way forces every field of the definition to be filled. Here is TC-P-min, the lower boundary case from the white paper's login example.

id: TC-P-min
title: Login of exactly 6 characters is accepted
condition: Login length, lower boundary of the valid partition (6 to 15)
requirement: REG-LOGIN-01
priority: high
preconditions:
  - The registration form is open
  - No account uses the login John99
test_data:
  login: John99
steps:
  - Enter John99 in the login field
  - Fill the other required fields with valid values
  - Select Register
expected_result: Login accepted
postconditions:
  - Delete the account created for John99

The requirement ID here is a placeholder for your own tracker's key. Once the record exists, a manual tester reads it as a checklist. Also, an automation script can loop over a folder of such files.

Which pages should you write test cases from?#

Start from the ISTQB glossary definition of a test case, then the Foundation syllabus chapter on test techniques, then the ISTQB boundary value white paper.

1. ISTQB glossary: test case, for the five parts every case must have.
2. ISTQB Foundation syllabus v4.0.1, chapter 4, for equivalence partitioning and boundary value analysis.
3. ISTQB Boundary Value Analysis white paper, for the login derivation step by step.
4. ISO/IEC/IEEE 29119-3, for the test documentation templates standard.

How is a test case different from a test scenario?#

A test scenario names what to check in one line, while a test case says exactly how, with data, steps and an expected result.

The ISTQB glossary has no core term called scenario. Instead, its nearest word is the test condition, "A testable aspect of a component or system". Test case vs test scenario is a common interview question, and the glossary settles it. So "login length is checked" is a condition or scenario, and TC-P-min is a case. Meanwhile ArtOfTesting, a tutorial site, describes a scenario as "generally a one-line statement" and says test cases are derived from it. And one more term sits above both. The glossary defines a test procedure as "A sequence of test cases in execution order". It adds the setup and wrap-up around them.

In short, the scenario is the what, the case is the how, and the procedure is the order. When a review comment says "this scenario is missing", it asks for a new condition. When it says "this case is unclear", it asks for better data, steps or results.

When is a scripted test case the wrong tool?#

A scripted test case is the wrong tool when the feature is new or unclear, because exploratory testing learns faster than steps written before anyone has used it.

Exploratory testing means designing and running tests in the same session, guided by what you just saw. So while the feature's behaviour is still unknown, a timed session finds the real questions. Our guide to exploratory testing with Rapid Reporter shows how to log one. Then write cases afterwards, for the behaviour that must stay true.

Where should you go after writing your first test cases?#

After the first set of test cases, the next skills are exploratory testing, defect triage and turning stable manual cases into automated checks.

When a case fails, the defect it reports needs a decision, and why bug triage discussions matter covers that meeting. Then, for why boundaries slip past the people who write the code, read the psychology of bugs. Once a case is stable, how manual testing improves automation quality shows how it becomes a script. Also, the login form has more conditions than length. The accessible forms guide lists the ones a screen reader user depends on.

If your team wants a QA (quality assurance) analyst to write and maintain its cases, see hiring a QA analyst. For forms that must pass an audit, see accessibility testing. Still, the three ISTQB documents above are enough to write effective test cases on your own.