Use Case Testing
How to read a use case (actors, preconditions, main success scenario, alternative and exception flows, postconditions) and turn every flow into test scenarios with measurable coverage.
A banking app ships a new “Forgot password?” flow. The tester walks through it on a phone: enter email, open the link, choose a new password, done. Every step works. A week later, support is busy: customers who opened the reset email on their laptop see a blank page, and customers who tapped an old link get logged in with no password change at all.
Nobody tested those routes because nobody wrote them down. A use case would have listed them on one page, and use case testing would have turned each one into a test.
What is a use case?
A use caseUse caseA step-by-step description of how a user reaches one goal with the system, including what can go differently.Open in glossary → describes, step by step, how someone uses the system to reach one goal, and what happens when things go differently along the way. Use case testingUse case testingTesting a complete user journey, the main path plus its alternative and error paths.Open in glossary → means deriving tests from it: one for the normal path, and at least one for every alternative and error path.
Use case testing is a black-boxBlack-box testingTesting based only on inputs and outputs, without looking at the code.Open in glossary → technique: you work from a description of behavior, not from the code. It’s great at finding bugs that live between screens: in the hand-offs, the branches and the “what happens next?” moments that single-field techniques like equivalence partitioning never reach.
The quick version
The parts of a use case
From flows to tests
- One test for the main success scenario, end to end.
- At least one test per alternative flow. Follow the branch and check it rejoins the main path correctly.
- At least one test per exception flow. Check the message, that nothing half-finished is left behind, and whether the user can recover.
- Check the postconditions, not just the last screen. “Password changed” on screen means little if the old password still works.
- Use other techniques inside the steps. The “new password” step still needs boundary values for its length rules.
Coverage
Use case coverage is simple: flows tested ÷ flows in the use case. Five flows and three tested means 60%. Aim for 100% of flows on important journeys, because most use case bugs hide in the alternatives and exceptions, which developers often build last and test least.
Use cases and user stories
Agile teams usually write user stories instead of formal use cases. The thinking is the same: a story’s acceptance criteria often describe the alternative and error paths. If a story only describes the happy path, ask “and what if…?” in refinement and you’re doing use case thinking.
The parts of a use case in depth
Use cases come from software design (Ivar Jacobson introduced them in the late 1980s, and they became part of UML). The structured, readable style most teams use today was popularized by Alistair Cockburn’s book Writing Effective Use Cases. Formats vary between companies, but these parts appear almost everywhere.
Actors
An actorActorWhoever or whatever interacts with the system in a use case: a person, another system or a device.Open in glossary → is anyone or anything that interacts with the system. The primary actor wants the goal: the customer resetting a password. Secondary actors help: the email service that sends the link, a payment provider, a restaurant’s tablet. Every actor is a hint for testing: what if the email service is slow? What if the payment provider declines?
Preconditions and trigger
PreconditionsPreconditionSomething that must already be true before you can start a test.Open in glossary → are what must already be true before the use case starts (“the customer has a verified email address”). In a test, preconditions become your setup, not something you check. The trigger is the event that starts the use case (“the customer taps Forgot password?”).
The main success scenario
The main success scenarioMain success scenarioThe use case's normal path, where everything goes right and the actor reaches the goal.Open in glossary → (also called the basic or main flow) is the story where everything goes right. It’s written as numbered steps that alternate between the actor and the system: “the customer enters their email”, “the system sends a link”. Keep it to roughly 3 to 9 steps; longer ones usually mix in details that belong elsewhere.
Extensions: alternative and exception flows
Everything that can go differently is listed as an extension, numbered after the step where it branches off. “3a” means “something different at step 3”, “3b” is a second thing that can happen at step 3.
- An alternative flowAlternative flowA different route through a use case that still reaches the goal.Open in glossary → is a different route that still reaches the goal: the customer opens the link on a computer instead of the phone, then continues normally.
- An exception flowException flowA route through a use case where an error or condition stops the actor from reaching the goal normally.Open in glossary → handles an error or condition that stops the normal path: the link has expired, the card is declined. The use case may end, or the user may recover and rejoin.
Postconditions
PostconditionsPostconditionWhat must be true after a use case or test has finished.Open in glossary → describe what must be true at the end. Good use cases list two kinds:
- On success: “only the new password works, other devices are logged out, the link can’t be used again”.
- If it fails (sometimes called the minimal guarantee): “the old password still works”. Even a failed run must not leave the system in a broken state.
Postconditions are gold for testers: they’re the checks people forget because the confirmation screen looks right.
A worked example: reset a forgotten password
Here’s the use case behind the hook story, written the way many teams do it:
Banking app
UC-07 Reset a forgotten password
- Primary actor
- Customer who can’t log in
- Other actors
- Email service
- Preconditions
- The customer has an account with a verified email address.
- The customer is logged out.
- Trigger
- The customer taps “Forgot password?” on the login screen.
Main success scenario (the happy path)
- 1The customer enters their email address and taps Send link.
- 2The system shows “If an account exists, we’ve sent a link” and emails a reset link valid for 30 minutes.
- 3The customer opens the link on the same phone.
- 4The system shows the New password screen.
- 5The customer enters a new password that meets the rules and taps Save.
- 6The system saves the password, logs out all other devices and shows “Password changed”.
Extensions (alternative and exception flows, numbered by the step where they branch off)
1a. The email address has a typo in its format Alternative
The system shows “Enter a valid email address”; the customer corrects it and continues at step 1.
3a. The customer opens the link on a computer Alternative
The website shows the New password screen; the flow continues at step 5.
3b. The link is older than 30 minutes Exception
The system shows “This link has expired” with a button to send a new one. The use case ends.
3c. The link was already used Exception
The system shows “This link has already been used”. The use case ends.
5a. The new password breaks a rule Alternative
The system explains which rule; the customer corrects it and continues at step 5.
- Postconditions on success
- Only the new password works.
- Other devices are logged out.
- The reset link can’t be used again.
- If it fails
- The old password still works.
The two bugs from the hook live right there: opening the link on a computer is extension 3a, and an old link is 3c. A tester working from this page would have tested both before release.
Deriving test scenarios step by step
- Read the whole use case and list its flows. Main success scenario, 1a, 3a, 3b, 3c, 5a: six flows.
- Write one scenario for the main flow. Use realistic data: a real-looking email, a password that meets the rules.
- Write one scenario per extension. Follow the main steps up to the branching point, take the branch, then either follow it back into the main flow or check that the use case ends cleanly.
- Add the postconditions to the expected results. After the main flow, try the old password (must fail), check another logged-in device (must be logged out) and tap the link again (must say it was used).
- Look for missing extensions. Read every system step and ask “what could go wrong here?” What if the email takes 10 minutes to arrive? What if the customer requests two links and uses the first one? Missing extensions are requirement gaps: raise them, just like gaps in a decision table.
- Apply other techniques inside steps. Step 5 has password rules, so use equivalence partitioning and boundary values there. The link’s life (fresh → used or expired) is a small state machine.
The result, as test scenariosTest scenarioA high-level idea of what to test, such as 'User resets a forgotten password'.Open in glossary →:
| Flow | Scenario | Key check |
|---|---|---|
| Main | Reset on the phone with a valid new password | Old password fails afterward |
| 1a | Type anna@ and tap Send link | Clear “valid email” message |
| 3a | Open the link on a laptop | New password screen appears |
| 3b | Open a link after 31 minutes | “Expired”, offer a new link |
| 3c | Open the same link twice | Second time: “already used” |
| 5a | Enter a too-short password | Rule explained, can retry |
Each scenario then becomes one or more detailed test casesTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary →; see how to write test cases and scenarios, cases and checklists.
Measuring coverage
Use case coverage counts flows, not steps:
coverage = flows exercised by at least one test ÷ all flows in the use case
Six flows with four tested is 67%. Two notes from practice:
- More tests ≠ more coverage. Ten variations of the main flow with different cards still cover only one flow. They may be worth running for other reasons (payment methods are risky), but count them honestly.
- 100% flow coverage isn’t “fully tested”. It means every documented route ran at least once. Data variations inside steps, undocumented routes and combinations of extensions (sold-out dish and declined card) are still open. Pick the risky combinations on purpose.
Use cases and user stories
Modern agile teams rarely write formal use cases; they write user stories with acceptance criteria. The two fit together well:
| User story | Use case | |
|---|---|---|
| Size | One small piece of value | A whole goal, end to end |
| Format | “As a…, I want…, so that…” + criteria | Numbered steps + extensions |
| Strength | Short, easy to plan in a sprint | Shows every branch in one place |
A tester can bring use case thinking into story refinement: sketch the main flow, then ask about each step “what else could happen here?” Each answer becomes an acceptance criterion, often in Given/When/Then form. Several stories (“reorder”, “handle sold-out dishes”, “show price changes”) often add up to one use case, and a use case is a great map for end-to-end tests across those stories.
Mobile and web twists
Real users don’t follow a use case in one sitting. When you test each flow, also ask what happens if the journey is split up:
- Across devices: the reset email opened on a laptop, a cart started on the web and finished in the app.
- Across time: the link opened tomorrow, the app reopened after it was closed from the app switcher halfway through.
- With interruptions: a phone call or a switch to the email app in the middle of a step. See interruptions and background and foreground.
- With the browser’s own controls: Back, refresh and opening the link in a second tab.
These aren’t always in the use case. When they’re missing, they’re excellent questions for the team, and good material for error guessing.
Common mistakes
- Testing only the main flow. The happy path is usually the part developers already tried themselves.
- Checking the last screen instead of the postconditions. “Order confirmed” doesn’t prove the customer was charged once.
- Treating preconditions as test steps. “Has a verified email” is setup; build it with test data, don’t re-test it in every case.
- Inventing behavior for a missing extension. If the use case doesn’t say what happens when every dish is sold out, ask. Don’t guess the expected result.
- Writing one giant test for all flows. If it fails at step 2, you learn nothing about the other branches. One flow per test keeps failures readable.
Practice: the use case workshop
Sort the product owner’s notes into the parts of a use case, then pick test scenarios. The coverage check tells you which alternative and exception flows you missed, and which picks add no new coverage.
🧭 Use case workshop: “Reorder a previous order”
The product owner of a food delivery app sent you loose notes. First sort them into the parts of a use case, then choose test scenarios and see which flows you covered.
Step 1 · Sort the notes
Alternative = a different route that can still reach the goal. Exception = an error or condition that stops the normal path.
The customer is logged in and has at least one completed order.
The customer opens Orders and taps Reorder on a past order.
If the cart already has items from another restaurant, the app asks whether to replace them.
If some dishes are sold out, the available ones are added and the missing ones are listed.
If the restaurant is closed, the app says when it opens and adds nothing.
The app adds the dishes to the cart at today’s prices and opens the cart.
If prices changed since the original order, the cart shows a “Prices updated” notice.
If the card is declined, the app keeps the cart and asks for another payment method.
The customer is charged once, and the original order is unchanged in the history.
Step 2 · Build your test scenarios
Pick the scenarios you would run. Aim to cover every flow and the postconditions without wasting tests.
Example test cases
These come from the “Reorder a previous order” use case in the workshop. Notice how each one names the flow it covers.
TC-UC-01Main flow: reorder a past order and pay by cardpositivehigh
Preconditions
- Logged in as a customer with a completed order from Pizza Roma
- Restaurant open, all dishes available, cart empty
Steps
- Open Orders
- Tap Reorder on the Pizza Roma order
- Check the cart and tap Place order
Expected result
Cart shows the same dishes at today’s prices; the confirmation appears; the card is charged once; the original order is unchanged in Orders.
TC-UC-02Alternative 2a: one dish sold outedgehigh
Preconditions
- Past order with 3 dishes; Tiramisu is marked sold out
Steps
- Tap Reorder on that order
- Read the message
- Place the order
Expected result
The 2 available dishes are added; a notice lists Tiramisu as unavailable; the total only includes the 2 dishes; the order can be placed.
TC-UC-03Alternative 1a: cart holds another restaurant’s items, choose Canceledgemedium
Preconditions
- Cart contains a lemonade from Burger Barn
Steps
- Tap Reorder on a Pizza Roma order
- Choose Cancel in the dialog
Expected result
The cart still contains only the lemonade; nothing from Pizza Roma was added.
TC-UC-04Exception 2c: restaurant closednegativemedium
Preconditions
- Pizza Roma is closed until 11:00
Steps
- Tap Reorder on a Pizza Roma order
Expected result
A message says the restaurant opens at 11:00; the cart is unchanged; no order is created.
TC-UC-05Exception 5a: declined card, then recoverynegativehigh
Preconditions
- Test card that is always declined, plus a second working test card
Steps
- Reorder a past order
- Pay with the declining card
- Choose the working card and pay again
Expected result
A clear decline message; the cart is kept; after paying with the second card there is exactly one new order and one charge.
Tip: click a test case to expand it.
Checklist
Use case testing checklist
0 of 9 checked
Check your understanding
Quick quiz
0/6 answered · 0 correct
1.In a use case, what is the main success scenario?
2.While reordering food, two of three dishes are available. The app adds those two and the customer still orders. What kind of flow is that?
3.A use case has a main flow, 3 alternative flows and 2 exception flows. Your tests cover the main flow and all alternatives. What is the flow coverage?
4.After a successful reorder, the confirmation screen appears. What else should the test check?
5.The use case doesn't say what happens if every dish in the old order is sold out. What should you do?
6.How do use cases relate to user stories?
Key takeaways
- A use case describes how an actor reaches one goal: preconditions, the main success scenario, alternative and exception flows, and postconditions.
- Derive at least one test per flow. Alternatives still reach the goal; exceptions handle errors that stop the normal path.
- Coverage = flows tested ÷ all flows. More variations of the happy path don’t add flow coverage.
- Always check the postconditions, not just the final screen.
- Missing extensions are requirement gaps: ask, don’t invent the expected result.
- In agile teams, bring the same thinking into user story refinement and end-to-end testing.
Finished this page?Nice work, this page is complete!
Mark it as done to track your progress. It's saved in this browser, no account needed.
Its review cards are now in Bites ⚡