How to write test cases
A test case is a short set of instructions that anyone on the team can run and reach the same verdict. It has a title that names what is checked and with which data, preconditions that describe the starting state, numbered steps, and an expected result for each step. Write one case per thing you check, use the labels exactly as the screen shows them, put real values instead of "valid data", and leave out the actual result: the run records Passed or Failed.
- 5 required parts
- out of the 9 a case can have
- 1 full example
- and 4 negative cases from it
- Case, scenario, checklist
- what each is for
How to write one, step by step
- Step 1
Start from the requirement
Read the story and its acceptance criteria. Each rule becomes one or more cases. If a rule is missing, ask the analyst; do not invent a limit the requirement does not give.
- Step 2
Choose the values
Split each input into partitions and boundaries, and give each value its own case. That is where the negative cases come from.
Open - Step 3
Write the title
Say what is checked and with which data: "Register with a 15-character username". Leave out the ID; the tool adds it.
- Step 4
Describe the preconditions
Describe a state, not an action: "Signed out; the username shelf_tester_15 is not taken". "Open the site" is a step.
- Step 5
Write the steps
Use short commands ("Enter", "Select"), never "I click". Name every button and field exactly as labeled on screen. Keep a case to about 10 steps.
- Step 6
Give each step its expected result
Write what should happen after each step, with the exact message where there is one. Decide it before the run, from the requirement.
- Step 7
Add the postconditions and the priority
Describe the state the case leaves behind, and set the case's priority by your team's rule. It is not the same as the story's priority.
What a test case is
A test case is a set of preconditions, inputs, actions and expected results written so that someone else can run it. Cases are grouped into suites: by module, by story, by type of testing, or into a regression suite that is run before every release.
A high-level case uses abstract values ("a valid username"); a low-level case uses concrete ones ("shelf_tester_15"). High-level cases leave room for variety, low-level ones give the same result on every run. A beginner should write low-level cases: they show exactly what was tested.
Test case, test scenario or checklist
A checklist is a list of short checks without steps, like a shopping list where each item is a check and the tick is its status. It suits early stages, requirements that still change and quick passes over a screen. A test case adds preconditions, steps and expected results, and suits complex business rules, regression suites, new team members and audits. Most projects use both.
"Test scenario" is a word from job ads rather than from a standard: a user's path through a business process that covers several checks, such as "a customer buys two books with a coupon and pays by card". One scenario gives many test cases. A scenario says what to test; a case says exactly how.
The parts of a test case
Five parts are required: ID, priority, title, steps and expected results. The other four are added when they help. A test case has no actual result field: the result of a run, such as Passed or Failed, is recorded separately each time the case is run.
ID (required)
Given by the tool, such as SHELF-12 in a test management tool. Never typed into the title.
Priority (required)
How important this case is to run, by the team's rule.
Title (required)
What is checked and with which data.
Steps (required)
Numbered actions with exact values and on-screen labels.
Expected results (required)
What should happen after each step.
Requirement link
The story or requirement the case checks.
Module
The part of the product: Sign-up, Cart, Checkout.
Preconditions and test data
The starting state and the data the case needs.
Postconditions
The state the case leaves behind.
A test case template
Copy this into a spreadsheet or a test management tool. In a spreadsheet, give each part its own column and each step its own row, so a step and its expected result sit side by side.
ID: <set by the tool> Title: <what is checked> with <which data> Priority: <High | Medium | Low> Requirement: <story or requirement> Module: <part of the product> Preconditions: <the starting state> Steps and expected results: 1. <action with exact data> -> <what should happen> 2. <action> -> <what should happen> Postconditions: <the state after the case>
A complete example
Shelf is the practice shop the courses use. Its sign-up page has the heading "Create an account", the fields Username and Password, and the button "Create account". A username takes 3 to 15 letters, digits or _; a password takes 8 to 72 characters.
This case checks the upper boundary of the username and the lower boundary of the password in one valid sign-up. Both values are valid, so one case can carry them; invalid values each get their own case, below.
Title: Register with a 15-character username and an 8-character password Priority: High Requirement: the registration story Module: Sign-up Preconditions: Signed out. The username shelf_tester_15 is not taken. Steps and expected results: 1. Open /register -> the "Create an account" form with Username and Password 2. Enter "shelf_tester_15" in Username -> no message 3. Enter "kettle42" in Password -> no message 4. Select "Create account" -> the account is created and the user is signed in Postconditions: The account shelf_tester_15 exists; the user is signed in.
Negative cases from the same form
Each invalid partition gets its own case, so that a failure points at one rule. The expected result is the message the requirement specifies, word for word. Run these after the positive case: if the valid sign-up fails, the negative cases tell you nothing.
Username of 2 characters
Enter "ab". Expected: "Use 3–15 characters: letters, digits or _."
Username of 16 characters
One character over the limit. Expected: the same message.
Password of 7 characters
One under the limit. Expected: "Use 8 to 72 characters."
Username taken in another letter case
"Shelf_Tester_15" after "shelf_tester_15" exists. Expected: "This username is taken. Try another one."
A weak case, fixed
Here is a case that looks finished and is not. It has eight problems. The ID is in the title, and the title has no data. The precondition is an action. The step says "I". "Valid data" has no values, so two people will test two different things. "The button" is not a label. There is one expected result for the whole case, and it cannot fail. And there is an actual result field. The complete example above is the same case with every problem fixed.
Title: TC-7 registration check Preconditions: Open the site Steps: I enter valid data and click the button Expected result: Everything works Actual result: OK
Where to learn this
13 lessonsQuestions and answers
What is the difference between a test case and a test scenario?
A test scenario is a user's path through a business process, such as buying two books with a coupon. A test case is one check on that path with exact preconditions, steps, data and expected results. One scenario usually gives several cases.
Does a test case have an actual result?
No. The case holds the expected results. Each time it is run, the run records the outcome, such as Passed, Failed, Blocked or Skipped. When a case fails, the actual result goes into the bug report.
How many steps should a test case have?
About 10 at most. Move setup into preconditions and checks of the final state into postconditions. A longer case usually checks several things and should be split.
One expected result per case, or one per step?
One per step is the standard form: when a step fails, you know which one. A case with a single expected result at the end happens, but it hides where things went wrong.
Can an AI assistant write my test cases?
It can write a draft, and you check every line against the requirement. Drafts often invent rules, merge several invalid values into one case, and write "an error message" instead of the exact text.
Do I need a test management tool?
Not to start: a spreadsheet works. A tool such as Qase or TestRail adds IDs, suites, runs and history. Keep the case status (Draft, Active, Deprecated) apart from the run result (Passed, Failed).
More guides
- Start hereHow to become a software testerWhat a software tester does, what to learn and in what order, and how to practice without a job: six steps from zero to a small portfolio.
- Bug reportsHow to write a bug reportThe fields of a bug report, a template to copy, a complete example from a practice shop, severity and priority with examples, and the mistakes that send a report back to you.
- Test designBoundary value analysis and equivalence partitioning, with examplesHow to split inputs into equivalence partitions, pick boundary values with the 2-value and 3-value methods, and choose the step, worked through four fields of a practice shop.
- Bug reportsSeverity vs priority, with examplesWhat severity and priority mean, who sets each, the scales teams use, and all four combinations worked through on one practice shop, with a short answer for interviews.
- Test documentationTest case vs test scenario vs checklistWhat a test scenario, a checklist and a test case are, one shop feature written all three ways, when to use which, and how a scenario turns into checklists and test cases.
- Test designHow to test a login pageTest cases for a login page derived from partitions, a decision table, boundaries and states, plus the security checks every login page needs, worked through on a practice shop.
- API testingAPI testing with Postman: a beginner's guideHow to send your first requests in Postman, read the response, keep addresses and tokens in variables, test 401 and 403, add a status check and run a collection, on a practice shop's API.
- API testingHow to test a REST API manually: a checklistA manual REST API testing checklist without code: reading the OpenAPI documentation, status codes, body, headers, 401 versus 403, negative cases and state, with example requests to a practice shop.
- DatabasesSQL for testers: check what the app savedHow testers use SQL: the queries that check what an online shop saved after an order (order row, items, payments), SELECT, WHERE, GROUP BY and JOIN on a real schema, and the mistakes to avoid.
- Web testingChrome DevTools for testers: how to collect evidence for a bug reportWhich Chrome DevTools panels a tester needs and how to use them to collect the Console error, the request, the server's response and the storage values that make a web bug report reproducible.
- Test processSmoke vs sanity vs regression testingWhat smoke, sanity, regression testing and retesting usually mean, why teams use the names differently, how to ask on a new team, and how to choose the checks for a new build.
- Mobile testingHow to test a mobile appWhat breaks only on a phone, how to choose between an emulator, a simulator and a real device, how to read the app's log and its traffic through a proxy, and a checklist to start from.
See the first course
The full outline of every course is available: you can see each lesson before you start.