A test case is only as good as its description. If it just says "check login", everyone tests something different, and a defect can hardly be reproduced later. Well-written test cases, on the other hand, are unambiguous, repeatable and can be automated when needed. This article shows how to write test cases: which structure has proven itself, which techniques help you find the right test cases and what matters in agile teams.
A test case describes under which preconditions, with which inputs and in which steps a specific behaviour of the software is checked, and which result is expected. The decisive part is the expected result: only the comparison between expected and actual behaviour turns using the software into a test.
Test cases do not stand alone. Which areas are tested at all, and how thoroughly, is defined in the test strategy and the test plan. Test cases put these decisions into practice at the operational level.
Whether in Jira, a test management tool or a spreadsheet, a good test case always contains the same building blocks.
More fields are possible but rarely necessary. Every additional mandatory field costs time in maintenance, and fields that are only partly filled in confuse more than they help.
Test cases are derived from requirements, user stories, process descriptions or interface specifications. Unclear or contradictory requirements surface particularly early when you write test cases. Clarify these questions before you continue. The article Clean requirements in IT projects explains why this matters so much.
First note what should be checked before deciding how. For a login, these could be: successful login, wrong password, locked account, lockout after several failed attempts, empty mandatory fields. This list quickly shows whether important cases are missing.
For each test condition, choose suitable input values. Proven techniques for this are described in the next section. They help you find as many defects as possible with few test cases.
Write preconditions, steps and expected results so that a knowledgeable person can test without asking questions. One action per step, concrete values, no room for interpretation.
Have test cases reviewed by a second person, ideally from the business side. Give each test case a priority based on risk, so that you know what to test first when time is short. The article Risk-based testing describes how.
Testing every conceivable combination is practically never possible. Test design techniques help you systematically pick a small but meaningful selection.
Suppose the requirement reads: "After three consecutive wrong password entries, the account is locked." The boundary is three failed attempts. Useful test cases therefore cover two, three and, as confirmation, four failed attempts. One of these test cases could look like this:
The test case for two failed attempts checks the counterpart: after the second failed attempt, logging in with the correct password must still be possible.
In Scrum teams, test cases are not written in a separate phase but together with the user story. Acceptance criteria are the most important test basis. The Given-When-Then format has proven itself: "Given an active account, when a wrong password is entered three times, then the account is locked." Criteria written this way are equally clear to the business, developers and testers and can be turned directly into automated tests. The article Agile testing in Scrum shows how testing works within the sprint as a whole.
Agile does not mean undocumented. Test cases for critical flows that are checked before every release belong in a maintained regression test suite. Many of them are good candidates for test automation.
Good test cases are not a form to fill in but the result of clear thinking: what should be checked, with which values, and how do you recognise success? If you derive test conditions carefully, use test design techniques and write every test case unambiguously, you find more defects with less effort and create a solid basis for regression testing and automation.
A good test case has a meaningful title, a link to the requirement, clear preconditions, concrete test data, short numbered steps and a precise, verifiable expected result. It checks exactly one test objective and can be executed independently of other test cases.
A test scenario roughly describes what should be checked, such as "customer orders as a guest". A test case makes this concrete with preconditions, test data, steps and an expected result. One test scenario usually leads to several test cases.
That depends on risk and complexity. Every requirement should have at least one test case for the happy path; invalid inputs, boundary values and special cases are added depending on their importance. Test design techniques such as equivalence partitioning and boundary value analysis keep the number manageable.
30-minute initial consultation — free and without obligation. We look at your test cases together and show how to find more defects with less effort.
Book a Free Initial ConsultationMore about our service: Software quality assurance and test management in Hamburg →