What Is Use Case Testing?

Use case testing derives test cases from use case documents — structured descriptions of how actors interact with a system to achieve goals. Each use case contains a main success scenario and alternative flows, providing natural test scenarios.

Use Case Anatomy

A well-written use case includes:

ElementDescriptionExample
NameBrief descriptive title“Place Order”
ActorWho initiates the interactionCustomer, Admin
PreconditionWhat must be true before startingUser is logged in, cart is not empty
Main flowStep-by-step happy path1. Select shipping… 2. Enter payment…
Alternative flowsDeviations from the main flow2a. Payment declined → show error
PostconditionWhat is true after successOrder is created, email sent

Example: Place Order Use Case

Actor: Registered Customer Precondition: Customer is logged in, cart has 1+ items

Main Flow:

  1. System displays cart summary with items and total
  2. Customer selects shipping method
  3. System calculates shipping cost and updates total
  4. Customer enters payment information
  5. System validates payment details
  6. Customer confirms order
  7. System processes payment
  8. System creates order and sends confirmation email
  9. System displays order confirmation page

Alternative Flows:

  • 2a. Only one shipping method available → system auto-selects it
  • 4a. Customer selects saved payment method → skip to step 6
  • 5a. Payment validation fails → system shows error, return to step 4
  • 7a. Payment processing fails → system shows error, suggest retry or different method
  • 7b. Payment timeout → system shows timeout message, order not created
  • 8a. Email service unavailable → order created, email queued for later
flowchart TD A[1. Display cart] --> B[2. Select shipping] B --> C[3. Calculate total] C --> D[4. Enter payment] D --> E[5. Validate payment] E -->|Valid| F[6. Confirm order] E -->|Invalid 5a| D F --> G[7. Process payment] G -->|Success| H[8. Create order + email] G -->|Fail 7a| D G -->|Timeout 7b| I[Show timeout] H --> J[9. Show confirmation]

Deriving Test Cases

Rule: Create at least one test case per flow (main + each alternative).

TCFlowDescriptionKey Steps
TC1MainHappy pathAll steps 1-9 succeed
TC22aAuto-select shippingOnly one method → auto-selected
TC34aSaved paymentSelect saved card → skip to confirm
TC45aInvalid paymentWrong card number → error → retry
TC57aPayment failsCard declined → suggest retry
TC67bPayment timeoutTimeout → order not created
TC78aEmail failsOrder created, email queued

7 test cases from 1 use case — each covering a distinct scenario.

Finding Missing Coverage

Use cases often reveal testing gaps. Ask:

  • What if the cart becomes empty between steps 1 and 6? (Concurrent modification)
  • What if the price changes during checkout? (Race condition)
  • What about the actor’s permissions? (Authorization)
  • What happens after the postcondition? (Order lifecycle)

Advanced Use Case Testing

Combining Flows

Real scenarios often combine multiple alternative flows in sequence:

TCCombined FlowsScenario
TC85a → MainPayment invalid, retry with correct data → success
TC97a → 4aPayment fails, use saved payment method → success
TC105a → 5a → 7aTwo invalid attempts, then valid but card declined

This combinatorial approach catches defects in flow transitions.

Use Case Testing for APIs

Map use cases to API call sequences:

Use Case: Place Order

Step 1: GET /cart → 200 (cart summary)
Step 2: PUT /cart/shipping → 200 (select shipping)
Step 3: GET /cart/total → 200 (recalculated total)
Step 4: POST /orders/payment-intent → 200 (payment info)
Step 5: POST /orders/validate → 200 or 400 (validation)
Step 6: POST /orders/confirm → 201 (order created)

Each alternative flow maps to an error response or different sequence.

Coverage Criteria

Flow coverage (minimum): Every flow executed at least once.

Step coverage: Every step in every flow executed at least once.

Data variation: Same flow with different valid/invalid data (combine with EP/BVA).

Extending Use Cases with Exception Scenarios

Beyond documented alternatives, test:

CategoryScenarios
TimeoutNetwork timeout at each step
ConcurrencySame user in two sessions
PermissionActor without required role
Data integrityReferenced data deleted mid-flow
SessionSession expires during flow

Exercise: Derive Test Cases from a Use Case

Use Case: Reset Password

Actor: Registered User Precondition: User has a registered account with verified email

Main Flow:

  1. User clicks “Forgot Password”
  2. System displays email input form
  3. User enters registered email
  4. System sends reset link to email
  5. User clicks link within 24 hours
  6. System displays new password form
  7. User enters new password (meeting policy: 8+ chars, 1 uppercase, 1 digit)
  8. System validates and saves new password
  9. System confirms password change and sends notification email

Alternative Flows:

  • 3a. Email not registered → system shows generic “If account exists, email sent” (security)
  • 5a. Link expired (>24 hours) → system shows “Link expired, request new one”
  • 5b. Link already used → system shows “Link already used”
  • 7a. Password doesn’t meet policy → system shows specific error
  • 7b. New password same as old → system shows “Choose a different password”

Task: Derive test cases for all flows. Add 2 additional exception scenarios not listed.

Hint

Think about: What if the user requests multiple reset links? What happens if the user’s account is locked/deactivated? What about SQL injection or XSS in the email field?

Solution

Test cases from documented flows:

TCFlowDescription
TC1MainHappy path: valid email → link → new password → success
TC23aUnregistered email → generic message
TC35aClick expired link → error message
TC45bClick already-used link → error message
TC57aPassword too short → specific error
TC67aPassword no uppercase → specific error
TC77aPassword no digit → specific error
TC87bSame as old password → rejection

Additional exception scenarios:

TCScenarioExpected
TC9Multiple reset requests → only latest link worksPrevious links invalidated
TC10Account deactivated/locked → request resetGeneric message (don’t reveal status)
TC11XSS in email field: <script>alert(1)</script>@test.comInput sanitized, no execution
TC12Concurrent: request reset, then change password normally, then click linkLink should be invalid

Total: 12 test cases covering documented flows + security + concurrency.

Pro Tips

  • Every alternative flow is a test case. Don’t skip them — alternative flows are where most defects hide.
  • Challenge preconditions. What happens if a precondition is NOT met? That’s another test scenario.
  • Think about postconditions. Verify not just that the action succeeded, but that all side effects occurred (emails sent, database updated, logs created).
  • Use cases pair well with exploratory testing. The documented flows guide structured testing; then explore beyond the documented paths.
  • Number your flows consistently. “5a” means “alternative at step 5, variant a” — this makes traceability easy when creating test cases.