How to Write Better Test Cases: Real Examples and Heuristics
Improve test cases with clearer intent, useful coverage, maintainable steps, and practical examples.
In this guide
A good test case communicates risk and expected behavior clearly enough that another person can execute or automate it. Precision, independence, and a useful oracle matter more than step count.
Start with behavior, not clicks
Keep account state, permissions, data, environment, and settings explicit rather than hiding half the scenario in undocumented setup.
Example: password reset
- Known and unknown emails receive the same privacy-safe confirmation.
- The link expires according to policy.
- A used link cannot change the password again.
- The new password works and the old one does not.
- Rate limiting does not disclose account existence.
Design data around boundaries and states
For a 1–100 quantity, useful values include 0, 1, 100, and 101. For workflows, test allowed and forbidden transitions. For roles, use a compact permission matrix.
Make expected results observable
“Works correctly” is not an expected result. Name what the user sees, the API returns, or the business state changes. Avoid implementation assertions unless they protect an important contract.
Review and maintenance checklist
- Protects a distinct risk or requirement
- Runs independently with controlled data
- Has an unambiguous pass/fail oracle
- Avoids duplicated navigation better handled as setup
- Lives at the fastest reliable test layer