How to write test cases
A test case can look complete and still fail its next reader. The steps are present, but the data is unclear, the expected result is a vague word such as successful and nobody knows what decision the check is meant to support.
Learning how to write test cases is less about filling every field. It is about creating a small, repeatable agreement between the person who runs the check and the person who needs to understand its result.
How to write test cases around a decision
Start with the behaviour that matters. Ask what could change the release or defect decision if it passed or failed. A case for a password reset may protect account recovery, not simply the presence of a green message.
Give the case a short purpose so a future maintainer can tell whether it still belongs in the suite. A title that names the condition and outcome is more useful than a sequence number.
Make preconditions and data usable by another person
Describe only the state required to begin: account status, permissions, feature flag, browser or data relationship. If the reader must guess how to create the state, the case is not repeatable yet.
Keep test data explicit but safe. Use placeholders or fixtures where real personal information would be inappropriate, and say which values are important to the observation.
Write steps that leave room for an observable result
Each step should contain one meaningful action. Avoid combining navigation, data entry and verification into a paragraph that hides the failure point. A good step tells the runner what to do and what state should exist before the next action.
The expected result should be visible or measurable: a record is created, a validation message appears, a request is rejected or a related value changes. Replace broad words such as works and correct with the observation the team can agree on.
Cover the nearby risk without multiplying the suite
Start with the main path, then choose nearby variations that could change the decision: missing data, a boundary value, an expired session or a second attempt. Do not copy the case for every imaginable input. Use an equivalence decision when several values should behave the same way.
Maintain cases as living evidence
After a change, ask whether the case still protects the same behaviour and whether its data can be prepared. Remove steps that no longer add evidence, update the wording and link a failure to the smallest useful context.
The strongest case is not the longest one. It is the one a teammate can run, understand and use to make a decision without a private translation.
How to write test cases: turn one risk into a repeatable check
Choose one behaviour in a small form or API endpoint. Write the risk, the required starting state, the minimum useful data and three actions. Stop before adding details that do not change the decision.
Give the expected result a visible observation. Ask another person to run the case from your notes. Mark every place where they had to ask for a hidden assumption.
Create one nearby variation and explain why it belongs. If you cannot name the risk it covers, keep it out of the case for now.
Questions before the next step
- What decision does this case support?
- Which starting state must be explicit?
- What exactly can the runner observe?
- Which variation changes the risk rather than merely the value?
Use focused questions and explanations to reinforce the principles behind test design and execution.
Explore ISTQB Quiz →