Use case testing | ComplexQA Wiki

Use case testing is a black-box test technique in which test cases are designed to exercise use case behaviors. A use case, in the definition of Ivar Jacobson and Alistair Cockburn, is all the ways of using a system to achieve a particular goal for a particular user. The test cases follow the main success scenario of the use case and each of its extensions: alternative paths, optional steps and errors.

Use cases come from requirements engineering. According to Cockburn, Ivar Jacobson invented what later became known as use cases in the late 1960s while working on telephony systems at Ericsson, and introduced them to the object-oriented community in the late 1980s. The structure described in this article follows Cockburn's book Writing Effective Use Cases (Addison-Wesley, 2001). In 2024 Jacobson and Cockburn published the Use Case Foundation, a joint definition of the concept. In testing, the ISTQB Foundation Level syllabus 2018 described use case testing as a separate technique; the syllabus 4.0 and its current version 4.0.1 no longer do. The ISTQB Advanced Level Test Analyst syllabus (version 4.0, 2025) treats use cases as models for scenario-based testing, and ISO/IEC/IEEE 29119-4:2021 describes scenario testing in clause 5.2.9.

The problem use case testing solves

Requirements are often written as a list of functions: the system validates the amount, the system sends a code, the system updates the balance. Each function can be tested on its own and still the user cannot reach the goal, because the functions do not work together in the order the user needs them. A list of functions also says little about what happens when something goes wrong in the middle of the flow.

A use case describes the flow from the point of view of the actor and the goal. It contains the main path and, step by step, the conditions under which the path deviates: a wrong input, a timeout, a refusal of an external system. Cockburn's method asks the authors to brainstorm all the things that could go wrong in the successful scenario. Defects of error handling are found on these failure paths, and a list of functions does not show them as paths.

Use case testing turns this structure into test cases. Each scenario of the use case becomes at least one test case, and the coverage of scenarios shows which paths of the user's goal have been checked.

History

The table lists the milestones of use cases in requirements and in testing standards.

Date	Event
Late 1960s	Ivar Jacobson develops what later became use cases at Ericsson, according to Cockburn
Late 1980s	Jacobson introduces use cases to the object-oriented community
2001	Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley
11 November 2019	ISTQB Foundation Level syllabus 2018 V3.1 describes use case testing in section 4.2.5
October 2021	ISO/IEC/IEEE 29119-4, second edition, with scenario testing in clause 5.2.9
2023	ISTQB Foundation Level syllabus 4.0: four black-box techniques, use case testing is not among them
15 February 2024	Cockburn announces the Use Case Foundation, written with Jacobson
2 May 2025	ISTQB Advanced Level Test Analyst syllabus 4.0 with scenario-based testing in section 3.2.3

Structure of a use case

Cockburn's fully dressed template collects everything that has to be true about one goal. The fields relevant for testing are:

Field	Meaning
Primary actor	The actor who initiates the use case to reach a goal
Scope	The system under design
Level	Summary goal, user goal or subfunction
Stakeholders and interests	Who else is affected and what they need protected
Precondition	What the system ensures is true before the use case starts
Minimal guarantees	What is protected even when the goal is not reached
Success guarantees	What is true when the goal is reached
Trigger	The event that starts the use case
Main success scenario	The numbered steps of the case in which nothing goes wrong
Extensions	Conditions that deviate from the main scenario and their handling
Technology and data variations	Different ways a step can be done, such as card or bank transfer

The Use Case Foundation calls the actor that initiates a use case the primary actor, and the actors the system calls upon supporting actors. An actor can be a person, an organization, a piece of software or a combination. In Cockburn's words, the preconditions and guarantees say what must be true before and after the use case runs.

Main success scenario and extensions

The main success scenario is the scenario in which nothing goes wrong. It is a numbered list of steps, each an action of an actor or of the system. The Use Case Foundation describes it as the normal, happy path to value, also called the basic flow.

An extension is a condition that can occur at a step of the main scenario, together with the steps that handle it. Extensions are numbered by the step where the condition is detected and a letter: 3a and 3b are two different conditions at step 3, and 3a1, 3a2 are the handling steps of 3a. Cockburn's guideline is that the condition says what was detected, for example "card expired", not what the actor did wrong. In the example below, some extensions return to a step of the main scenario, and others end the use case without reaching the goal.

The Test Analyst syllabus distinguishes the same parts with other names: the main scenario, extensions, also called alternative scenarios, and exceptions, which fail to reach the goal because of unexpected actions or invalid input. The Use Case Foundation calls extensions alternate flows.

Forms of a use case

Cockburn names two forms of writing. The casual form "short circuits" the template and is written as a short narrative paragraph. The fully dressed form uses the full template and the step numbering. According to Cockburn, casual use cases suit low-ceremony projects and fully dressed ones higher-ceremony projects, and neither is wrong.

He also describes four levels of precision, from the actor's name and goal to the full handling of each extension:

Precision level	Content	Supports in test design
1	Primary actor and goal	Scope of testing
2	Use case brief or main success scenario	Main path test case
3	Extension conditions	List of test cases
4	Extension handling steps	Expected results of each test case

A use case at level 2 is enough for one test case. Test cases with expected results for the failure paths need level 4: without the handling steps, the tester does not know what the system should do when the condition occurs.

A worked example

The example is a fictional use case of an online bank in fully dressed form, shortened to the fields used for testing.

Field	Value
Use case	UC-7 Transfer money between own accounts
Primary actor	Customer
Supporting actor	SMS gateway
Level	User goal
Precondition	The customer is logged in and has at least two accounts
Minimal guarantees	No money is moved without a confirmed code; every attempt is logged
Success guarantees	The amount is debited from the source and credited to the target; both balances and the history show it
Trigger	The customer selects "Transfer"

Main success scenario:

The customer selects the source account, the target account and the amount.
The system validates the transfer and shows a summary.
The customer confirms the transfer.
The system sends a one-time code through the SMS gateway.
The customer enters the code.
The system performs the transfer and shows a confirmation.

Extensions:

2a. Amount exceeds the available balance. 2a1. The system shows the available balance. The use case continues at step 1.
2b. Amount exceeds the daily limit. 2b1. The system shows the remaining limit. The use case continues at step 1.
3a. The customer cancels. The use case ends without a transfer.
5a. The code is wrong. 5a1. The system asks for the code again. 5a2. After the third wrong code the system cancels the transfer and the use case ends.
5b. The code has expired. 5b1. The system offers a new code. The use case continues at step 4.

From a use case to test cases

The Test Analyst syllabus describes the derivation as building a scenario model from the action sequences of the use case and designing test cases that cover its scenarios. A scenario is a complete sequence of steps through the whole use case. Each extension adds at least one scenario: the main path up to the condition, the handling steps, and the rest of the path to success or to failure.

The scenarios of UC-7 and their test cases:

Test case	Scenario	Steps	Expected result
UC7-1	Main success scenario	1-6	Balances changed, transfer in history
UC7-2	2a, then success	1, 2, 2a1, 1-6	Available balance shown, then transfer done
UC7-3	2b, then success	1, 2, 2b1, 1-6	Remaining limit shown, then transfer done
UC7-4	3a	1-3, 3a	No transfer, attempt logged
UC7-5	5a once, then success	1-5, 5a1, 5, 6	Second code accepted, transfer done
UC7-6	5a three times	1-5, 5a1, 5, 5a1, 5, 5a2	Transfer cancelled, balances unchanged
UC7-7	5b, then success	1-5, 5b1, 4-6	New code sent, transfer done

The fields of the use case go into the parts of the test case. The precondition becomes the precondition of the test case: a logged-in customer with two accounts. The trigger is the first step. The success guarantees are the expected result of every test case that reaches the goal, the minimal guarantees of every test case that fails: in UC7-4 and UC7-6 the test checks that no money has moved and that the attempt is in the log. The structure of a test case is described in the article Test case.

Supporting actors determine the test environment. The SMS gateway of UC-7 is an external system; tests of 5a and 5b need a way to receive the code or a test double that returns a known code and can let it expire.

A scenario fixes the path, not the data. The amount in UC7-2 has to be above the balance, and the boundary between "within the balance" and "above the balance" is tested with the values chosen by equivalence partitioning and boundary values. One scenario can therefore lead to several test cases, one per value.

Coverage of a use case

The Test Analyst syllabus measures scenario coverage as the number of executed scenarios divided by the number of identified scenarios. In UC-7 seven scenarios are identified, and the seven test cases above cover them all. In the syllabus 2018 of the Foundation Level the same idea was expressed as the number of use case behaviors tested divided by the total number of behaviors.

Coverage depends on which scenarios are identified. Two kinds of paths are not obvious:

Combinations of extensions. A customer can exceed the balance (2a), correct the amount and then enter a wrong code (5a). Covering each extension once does not cover such combinations; the syllabus recommends prioritizing scenarios by risk.
Loops. Extension 5a is a loop. For paths with loops the syllabus applies simple loop coverage: zero iterations, one, more than one, and the maximum where possible. For 5a these are a correct code at once (UC7-1), one wrong code (UC7-5), two wrong codes, and three wrong codes (UC7-6).

Covering every extension is not the same as covering every requirement behind it. A use case can be complete as a flow and still omit a rule, for example a different daily limit for business customers. Use case coverage is read together with requirements coverage.

Use cases, user stories and acceptance criteria

A user story, in the ISTQB glossary, is a requirement of one sentence in everyday or business language that captures the functionality a user needs and the reason behind it, together with acceptance criteria. A story is usually smaller than a use case: it can describe one step, one extension or one variation. The ISTQB Foundation Level syllabus 4.0.1 places this work in section 4.5, collaboration-based test approaches: collaborative user story writing, acceptance criteria and acceptance test-driven development. Cockburn has published a book about the relation between the two, Unifying User Stories, Use Cases, Story Maps.

The two descriptions map onto each other. The main success scenario corresponds to the story of the main need, each extension to one or more acceptance criteria of a story: "a wrong code can be entered three times", "an expired code can be replaced". A use case gives the context that individual stories lack: the order of the steps and the full list of things that can go wrong.

Gherkin scenarios

Gherkin scenarios are one way to write acceptance criteria that can also be executed. Cucumber's reference describes Given as putting the system into a known state, When as the action and Then as the expected outcome; steps shared by all scenarios of a feature go into Background. Each scenario of a use case becomes a Gherkin scenario. Two scenarios of UC-7:

Feature: Transfer money between own accounts

  Background:
    Given the customer is logged in
    And the account "Current" has a balance of 500.00 USD
    And the account "Savings" has a balance of 0.00 USD

  Scenario: Transfer within the balance
    When the customer transfers 200.00 USD from "Current" to "Savings"
    And the customer confirms the transfer with a valid one-time code
    Then the balance of "Current" is 300.00 USD
    And the balance of "Savings" is 200.00 USD
    And the transfer appears in the transaction history

  Scenario: Third wrong code cancels the transfer
    When the customer transfers 200.00 USD from "Current" to "Savings"
    And the customer enters a wrong one-time code 3 times
    Then the transfer is cancelled
    And the balance of "Current" is 500.00 USD
    And the attempt is logged

The precondition of the use case goes into Background, the steps of the scenario into When, the guarantees into Then. The minimal guarantees become the Then steps of the failure scenario. Gherkin scenarios derived from a decision table instead of a use case are described in decision table testing.

Several techniques also work with sequences or with business-level descriptions. The table compares them.

Technique	Model	Coverage items	Point of view
Use case testing	Use case with scenarios	Main scenario, extensions, exceptions	Actor and goal
State transition testing	States, events, transitions	States, transitions	Object and its events
Decision table testing	Conditions, actions, rules	Feasible columns	One business rule
Acceptance criteria of user stories	Story with criteria	Criteria	One user need

A use case and a state model describe sequences from different points of view. A use case follows one actor toward one goal and passes through several states of the objects it touches. A state model follows one object through all events from all actors. State transition testing finds events in the wrong state, which a use case usually does not mention.

Inside a single step, the use case often hides a rule with several conditions: step 2 of UC-7 checks both the balance and the daily limit. Such a rule is tested with a decision table, and the use case then contributes the path, the table the combinations.

Terms

Term	Meaning
Use case testing	Black-box test technique in which test cases are designed to exercise use case behaviors
Use case	All the ways of using a system to achieve a particular goal for a particular user
Primary actor	The actor that initiates a use case to achieve a goal
Main success scenario	Numbered steps of a use case in which nothing goes wrong
Extension	Condition at a step of the main success scenario, together with the steps that handle it
Minimal guarantees	What a use case protects even when the goal is not reached
Success guarantees	What is true after a use case has reached its goal
Scenario	Complete sequence of steps through a use case
User story	One-sentence requirement in everyday or business language with the functionality a user needs, the reason and acceptance criteria