A test case connects a risk or requirement to a repeatable action and an observable result. More steps do not automatically make a better test.
A useful test case lets another person understand what is being checked and recognise whether the result is acceptable. It should remove important ambiguity without documenting every mouse movement. The level of detail depends on who will use it and how complex the feature is.
Start by asking why the check matters. If you cannot connect a case to a requirement, user goal or risk, clarify its purpose before spending time formatting it.
- Set up the data
- Describe the action
- Check the outcome
Capture the information needed to repeat it
Give the case a stable identifier and a title describing the behaviour. Include the starting state, important test data, actions and expected result. Record actual results separately when you execute it; a written expected result is not evidence that the feature passed.
Avoid vague expectations such as 'works correctly' or 'successful'. State what the user should see and, where relevant, which underlying outcome must occur. A success message without a saved booking could hide a serious failure.
| Field | Worked example |
|---|---|
| ID and purpose | BOOK-04: Reject a booking before the permitted start date |
| Precondition | Booking opens on 7 September; learner has no existing booking |
| Data | Choose 6 September in the same year |
| Action | Complete valid contact details and submit |
| Expected | Explain the permitted date; create no booking; retain correct form values |
| Actual | Complete during execution, with evidence |
Choose data that investigates a boundary
Suppose a workshop accepts groups of one to six people. Testing groups of two and three may repeat the same rule. Values around the limits—zero, one, two, five, six and seven—ask more distinct questions. Empty input and non-numeric data introduce additional input-handling risks.
These examples assume a stated rule. If the rule is missing, record an assumption and ask for clarification. Also consider how values are entered: typing a negative number, pasting text and using a numeric control might follow different paths. Select the paths that fit the actual product.
Check what changes after an action
Many defects live between states. A learner might move from available to booked, then cancelled. Ask whether cancellation releases a place, whether a second cancellation is safe and whether an old confirmation link remains meaningful.
Write the starting state explicitly. A case that depends on the previous tester's booking history may pass one day and fail the next. Use clear setup instructions and unique practice data, or explain how the environment is reset. Predictable setup helps both manual execution and later automation.
Use the right amount of detail
Detailed steps are useful for unfamiliar or regulated workflows, handovers and precise reproduction. A focused checklist can work well for an experienced team checking a familiar feature. An exploratory charter instead describes a mission and risks, leaving room for investigation.
Do not force every testing activity into the same template. A case for a stable validation rule and a session exploring confusing navigation need different levels of freedom. Choose the format that preserves intent and evidence without making the work unnecessarily slow.
Review cases as the product changes
Ask someone else to execute one case without verbal help. Every clarification they need reveals an opportunity to improve the data, starting state or expected result. Remove duplicated checks and keep links to the requirement or risk where they help future review.
When a requirement changes, update the relevant cases and record why. A large collection of outdated cases can give false confidence. A smaller, maintained set with clear coverage and known gaps is more useful for release decisions and learning.
Improve a weak test case
- Start with: Enter valid details and check registration works
- Specify the starting state and exact test data
- Write the observable success outcome and stored result
- Add one invalid-input case and one repeated-submission case
Build these skills with support
Explore live courses with guided practice, projects and space for questions.
Create Your AccountOur practical examples are learning exercises. References are linked beside the relevant sections. Course fees, schedules and access terms are maintained on the course pages. Tell us if something needs correcting.
