How to Write Test Cases: A Practical Step-by-Step Guide
A useful test case explains what risk is being checked, the state required before execution, the exact action to perform and the observable result. This guide shows a repeatable method that works for web, mobile and API testing.
Start with the requirement and its risks
Read the requirement before writing steps. Identify the user, action, business rule and intended outcome. Then list what could fail: invalid input, missing permissions, unavailable dependencies, duplicate submission, boundaries and interrupted workflows.
When a rule is unclear, record the assumption or question instead of silently inventing behaviour. A test case based on an unconfirmed rule can look complete while validating the wrong product.
Practical checklist
- Who performs the action?
- What state must already exist?
- What is the primary success path?
- Which failure would have the greatest impact?
- Which limits or boundaries are documented?
Use a consistent test case structure
Give every case a unique ID and a title that states the behaviour being verified. Keep preconditions separate from actions. Write numbered steps in execution order and make the expected result specific enough that two testers can reach the same conclusion.
Include test data only when the value affects the result. Avoid hiding important values inside long step descriptions.
Write observable expected results
Avoid vague results such as ‘works correctly’ or ‘successfully completed.’ State what the tester can observe in the interface, API response, database or downstream system.
For critical workflows, include both the user-facing outcome and the important state change. A payment confirmation message alone does not prove that exactly one paid order was created.
Practical checklist
- Visible message or destination
- Created or updated system state
- Status code or response contract when relevant
- No unintended duplicate or side effect
- Security and permission outcome
Cover more than the happy path
Begin with the main success path, then add negative, boundary, security, usability and accessibility coverage according to risk. Not every field needs dozens of cases, but critical rules should be checked at valid, invalid and boundary values.
Prioritise cases using business impact and probability. High-priority cases should protect the flows that affect money, access, privacy, core data or a large number of users.
Practical checklist
- Functional success
- Required and invalid inputs
- Minimum and maximum boundaries
- Permissions and unauthorised access
- Keyboard and assistive technology
- Network failure, retry and duplicate prevention
Review before execution
Ask another tester, developer or product owner to review cases that rely on unclear rules. Remove duplicate cases, separate cases that contain several unrelated objectives and confirm that every expected result is testable.
Test cases are maintained assets. Update them when the requirement changes and retire cases that no longer protect a relevant risk.
Practical checklist
- One clear objective per case
- No missing setup or hidden dependency
- Numbered and reproducible steps
- Specific expected result
- Priority reflects actual risk
Key takeaways
- Write from confirmed rules and explicit risks.
- Separate preconditions, steps, data and expected results.
- Use observable outcomes instead of vague language.
- Cover negative and boundary behaviour according to risk.
- Review and maintain cases as the product changes.
Put it into practice
Open Test Case Generator
See examples
Browse test case examples
Related practical guides
How to create a test plan
Create a practical software test plan covering scope, risks, environments, test levels, responsibilities, entry and exit criteria.
Regression testing guide
Learn how to select, prioritise, maintain and automate a practical regression test suite without testing everything every time.
How to test a mobile application
A practical mobile application testing guide covering devices, installation, permissions, networks, interruptions, accessibility and security.