From Use Cases to Test Cases

From Use Cases to Test Cases

A well-written use case scenario is not just a requirements artifact — it is the seed of an acceptance test. Every flow you documented in the previous lesson (main success flow, alternate flows, exception flows) maps directly to at least one test case. Analysts who understand this connection write sharper scenarios, and testers who understand it spend far less time inventing test inputs from scratch.

This lesson shows you the systematic technique for deriving a complete set of test cases from use case scenarios, using a clinic booking system as the running example.

Why Use Cases Make Great Test Seeds

Use case scenarios share three properties with test cases: they describe a precondition (the system and actor state before the interaction begins), a sequence of steps (actions and system responses), and a postcondition (what must be true when the scenario ends successfully or fails). Because that structure already exists in your scenario, you are not writing tests from scratch — you are translating existing analysis work into a test format.

The mapping rule is simple:

• Each main success flow yields one happy-path test case.
• Each alternate flow yields one or more variation test cases.
• Each exception flow yields one or more negative test cases.
• Each extension point (where an extend use case can trigger) yields tests for both the triggered and the non-triggered paths.

The Translation Technique — Step by Step

The following five steps convert a use case scenario into a formal test case specification. We will apply them to the Book Appointment use case from the clinic booking system.

Step 1 — Identify the scenario

List every scenario (main flow + all alternate and exception flows) in your use case. Give each one a short label. For Book Appointment:

• BA-S1 — Patient books a valid appointment (main success flow)
• BA-S2 — No available slots on selected date (alternate flow)
• BA-S3 — Patient provides invalid ID format (exception flow)
• BA-S4 — System timeout during slot confirmation (exception flow)

Step 2 — Assign preconditions and test data

Each scenario's precondition from the use case becomes the test's Given clause. Specify concrete test data: real doctor names, specific dates, exact ID strings. Concrete data makes tests repeatable and removes ambiguity about what "valid" means.

Step 3 — Derive the test steps

Each step in the scenario flow becomes a test action or system-check. Actions driven by the actor become When steps; expected system responses become Then assertions.

Step 4 — State the expected outcome

The postcondition of the scenario becomes the test's pass/fail criterion. For the main success flow, the expected outcome is a confirmation. For exception flows, the expected outcome is an appropriate error message and a stable system state.

Step 5 — Add boundary values and equivalence classes

Once you have the scenario-derived tests, augment each one with boundary values: the minimum and maximum allowed inputs, and values just outside those limits. This step is where use-case-derived tests and classic test design techniques (equivalence partitioning, boundary value analysis) intersect.

Diagram 1 — Mapping Flows to Test Cases

The diagram below illustrates how the three types of scenario flows in Book Appointment fan out into test cases, and how boundary-value augmentation adds additional coverage.

A Complete Test Case Derived from a Scenario

Below is the full specification for TC-BA-01, derived directly from the Book Appointment main success flow. Notice how the structure mirrors the use case scenario fields.

Contrast this with TC-BA-03, derived from the exception flow "Patient provides invalid ID format":

Diagram 2 — Coverage Matrix: Scenarios vs Test Cases

A test coverage matrix traces each test case back to the scenario that seeded it. It answers the question: "Have we covered every scenario?" and is a required deliverable in most formal QA processes.

Applying the Technique Beyond Booking

The same technique scales to any domain. For an online store use case Place Order, the main success flow seeds a happy-path test; the alternate flow "item becomes out of stock during checkout" seeds a variation test; and exception flows "payment gateway refuses card" and "shipping address not serviceable" each seed a negative test. For a library system use case Renew Loan, the alternate flow "maximum renewals reached" and the exception flow "item reserved by another patron" both become distinct negative tests.

The pattern is universal. If your scenario documents are thorough — if they cover all the alternate and exception flows described in the previous lesson — your test suite will achieve broad acceptance coverage almost automatically.

When a Scenario Is Missing

Working backwards also works: if testers invent a test case that cannot be traced to any documented scenario, that is a sign your use case model is incomplete. The test case reveals a flow you forgot to document. Add the missing scenario to your use case write-up, update the traceability matrix, and investigate whether it also exposes a missing requirement in the system specification. This bidirectional traceability — from requirement to test and back — is one of the most powerful quality mechanisms in structured analysis.

Summary

Every scenario in a use case write-up — main success flow, alternate flows, exception flows — maps directly to one or more acceptance test cases. The translation follows a consistent five-step process: identify the scenario, assign preconditions and test data, derive test steps, state the expected outcome, and augment with boundary values. A traceability matrix links each test case back to its source scenario and reveals gaps in coverage. When every scenario has a test and every test has a scenario, you have achieved full acceptance coverage of your use case model.