Use Case Testing

Why it matters

Users work through tasks, and tasks branch. Defects often hide where a flow branches, where it rejoins and in error handling: a customer charged twice after a timeout, an order created without payment, a cart emptied after a failed payment. Happy-path tests never visit these places, yet that is where failures cost money and trust.

For the tester, a use case turns a requirement into a countable list of scenarios. You can report "five of six checkout flows pass, the timeout flow fails" instead of "checkout mostly works", and reading a use case as a tester exposes missing flows before any code exists.

What a use case contains

In ISTQB terms, a use case is a sequence of interactions between an actor and the system with a tangible result. The actor can be a user or anything else that exchanges information with the system, and it is a role, not a person: "customer" or "payment gateway". The primary actor starts the use case to reach its goal; supporting actors are the people or systems needed on the way.

Names differ between templates — some teams call every branch an "extension" — but every branch must say where it leaves the main flow and where it ends. A typical use case has:

• Name: the goal as a verb phrase, such as "Place an online order".
• Precondition and trigger: what must be true before it starts, and the event that starts it.
• Main flow (also basic flow or main success scenario): the numbered steps of the usual path to the goal.
• Alternative flows: other valid paths with no error, usually ending at the same goal, such as paying with a new card.
• Exception flows: the system’s response when something goes wrong — invalid input, a business rule that blocks a step, a supporting system that refuses or does not answer. The flow either recovers, so the goal can still be reached, or ends the use case safely without the goal.
• Postconditions: what is true at the end, on success (order stored) and on failure (nothing charged, cart kept); the failure side is often forgotten.

Worked example: a checkout use case

A business analyst wrote this use case for an online shop. Read it as a tester: count the flows and note where each one leaves the main flow and where it ends.

There are six flows: the main flow, two alternative flows and three exception flows. E1 recovers into the main flow; E2 and E3 end without a paid order, so their tests must check what must not happen: a second payment request, a charge without an order, a lost cart.

UC-07  Place an online order
Primary actor:     Customer (signed in)
Supporting actor:  Payment gateway
Precondition:      The cart holds at least one item in stock
Trigger:           Customer selects "Checkout"

Main flow
1. System shows the items, the total and the saved delivery address.
2. Customer confirms the address.
3. Customer chooses the saved card and selects "Pay".
4. System sends one payment request; the gateway approves it.
5. System creates the order as Paid, reduces stock, empties the cart
   and shows the order number.

Alternative flows
A1 at 2  Customer adds a new address; system validates it. Rejoins at 3.
A2 at 3  Customer enters a new card. Rejoins at 4.

Exception flows
E1 at 4  Gateway declines: system shows the reason. Back to 3.
E2 at 4  No reply within 30 s: system shows "Payment being confirmed",
         records the order as Pending, sends no second request. Ends.
E3 at 5  An item sold out during payment: system voids the payment,
         keeps the cart and tells the customer. Ends.

Deriving test cases from the flows

Each flow is a coverage item, so the minimum is one test per flow. A branch test follows the main flow to the branch point, triggers the branch and follows it to its end. If the branch rejoins further on, as A1 and A2 do, the test completes the main flow to show that the goal is still reached. If it loops back to an earlier step, as E1 does, the test checks that the actor is back at that step with nothing half done: no order, no charge.

• Precondition → test setup; trigger → first step; postconditions → expected results.
• Check data, not only the screen: the order status, the stock level and the payment record in the gateway’s test environment.
• Plan how to trigger every exception: a test card that the gateway’s sandbox (the test version of the service, run by the provider) always declines, a stub (a stand-in for the gateway that the team controls) that delays the reply, a second test user who buys the last item. A branch nobody can trigger quietly drops out of testing, so raise it early.
• Inside the steps, reuse earlier techniques: boundary values for the address fields, state transitions for the order status (Pending, Paid).

TC-07-01  Main: saved address and saved card
          Expect: order Paid, stock reduced, cart empty, order number shown
TC-07-02  A1: new valid address at step 2
          Expect: order Paid with the new address on it
TC-07-03  A2: new test card at step 3
          Expect: order Paid with the new card
TC-07-04  E1: a sandbox card that the gateway declines
          Expect: reason shown, back at step 3, no order, nothing charged
TC-07-05  E2: a stub delays the gateway reply beyond 30 s
          Expect: message shown, order Pending, exactly one payment request sent
TC-07-06  E3: a second user buys the last unit during payment
          Expect: payment voided, no order, cart kept, customer told

Try it: User Story → Test Scenarios Try it: Requirements → Test Scenarios

Use case coverage and its limits

Use case coverage is the number of flows exercised by at least one test divided by the number of flows identified, as a percentage. A suite that runs only the main flow, A1 and E1 covers 3 of the 6 flows of UC-07: 50%. The six tests above reach 100%.

Full flow coverage is the minimum. For risky use cases, add combinations, such as a decline followed by a new card (E1 then A2). And flow coverage says nothing about the flows nobody wrote, so ask at each step what else could happen:

• The actor cancels, goes back or waits until the session expires.
• The actor repeats an action: double-clicks "Pay" or refreshes during payment.
• A supporting system is slow, unavailable or answers twice.
• Another user changes the same data at the same moment.

Try it: Requirements → Test Cases

Frequently asked questions

References

• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.