Use Case in Software Testing: How to Turn One Into Test Cases

A use case shows a tester every path one kind of user can take to reach one goal with the system, step by step, with the alternative paths and the failures included. Use case testing turns each of those paths into at least one test case and runs it from end to end.

The Object Management Group's UML 2.5.1 specification says a use case specifies a set of actions performed by its subjects, which yields an observable result of value to one or more actors or other stakeholders.

Related reading: the software testing checklist, grouped by test phase, and how a QA maturity assessment scores the test process these techniques sit in.

What is a use case in software testing?

Ivar Jacobson introduced use cases in the late 1980s, and his 1992 book is titled Object-Oriented Software Engineering: A Use Case Driven Approach. A paper by Jacobson and Alistair Cockburn, Use-Case Foundation, defines a use case as all the ways of using a system to achieve a particular goal for a particular user. Its structure, a basic scenario plus its extensions, works as a map of how the system will be used. A complete use case tells the whole story, from the initial event to the realization of the value or the eventual failure, and includes the normal expected sequence, the special cases, the optional steps and the errors the system needs to handle.

In requirements engineering and software testing, a use case is a structured document with specific parts, and the International Requirements Engineering Board defines it as a set of possible interactions between external actors and a system that provide a benefit for the actors involved. People outside testing often use the phrase to mean a situation a product might be used for.

Who writes the use case varies from team to team, with a business analyst or product owner a common choice, and testers design their tests from whatever version exists.

What does a use case contain that a tester can use?

Each field of a use case written to Alistair Cockburn's template gives the tester a piece of the test design. The International Software Testing Qualifications Board (ISTQB) adds one more type of path in its Advanced Test Analyst syllabus, the exception, which ends without the goal being reached.

How do you write test cases from a use case?

Writing test cases from a use case means naming every path through it, then giving each path the data, preconditions and expected results that make it executable.

Start by listing the paths. A use case has exactly one main scenario and any number of extensions and exceptions, and every path needs to run at least once. ISTQB's earlier Advanced Test Analyst syllabus set the minimum acceptable coverage at one test case for the basic behavior, plus enough additional test cases to cover each alternative and error-handling behavior. Then rank the paths by business risk and by how often users take them, so the test cases covering the most important risks run first, which is how ISTQB describes risk-based prioritization. Jacobson and Cockburn note that a use case can be built in stages, key scenarios first and less critical ones later, and the test cases can follow the same order.

Each path starts as a high-level test case and becomes one or more low-level test cases ready to run. In ISTQB's Advanced Test Analyst syllabus, a high-level test case states which test conditions it covers, and a low-level test case carries concrete preconditions, input data, expected results and postconditions.

Design the data for each path with equivalence partitioning and boundary value analysis, which is why one scenario may need more than one test case. Equivalence partitioning divides data into partitions the system processes in the same way, and boundary value analysis focuses on the edges of those partitions, where developers are more likely to make errors. A step that takes a transfer amount needs test cases for valid amounts, amounts exceeding the daily limit, and amounts leaving a zero balance. Where the scenario contains a loop, apply simple loop coverage, which tests the loop with zero iterations, exactly one, more than one and the maximum number of iterations. A retry behavior on a payment gateway needs all of those counts to verify that the system recovers correctly and terminates when the maximum is reached.

A use case is a guideline and may not define everything that should be tested, as ISTQB's earlier Advanced syllabus warned, so some steps need a technique of their own. Use decision table testing where a step applies business rules, with each feasible column of the table as a coverage item, and state transition testing where the response to an event depends on the state the system is in. Combining suitable techniques, the same syllabus says, is often the most effective way to reach the test objectives.

What does use case testing look like in a worked example?

A customer moving money between their own accounts makes a compact example: one goal, two alternate flows and two exceptions.

Use Case: Transfer Funds Between Own Accounts

• Primary Actor: Authenticated Bank Customer

• Goal: Transfer funds from a checking account to a savings account.

• Preconditions: The customer is logged in and has at least two active accounts.

• Trigger: The customer selects the internal transfer option.

• Main Success Scenario:

  1. The system prompts for the source account, destination account, and amount.

  2. The customer selects a valid source account.

  3. The customer selects a valid destination account.

  4. The customer enters an amount within the available balance and daily limit.

  5. The system requests confirmation.

  6. The customer confirms the transfer.

  7. The system deducts the amount from the source, adds it to the destination, and displays a success message with a reference number.

• Extensions (Alternate Flows):

  • Alt 4a: The customer enters an amount exceeding the available balance. The system displays an insufficient funds error and asks for a new amount.

  • Alt 4b: The customer enters an amount exceeding the daily transfer limit. The system displays a limit error and asks for a new amount.

• Exceptions (Failure Flows):

  • Exc 6a: The customer cancels the transfer at the confirmation screen. The system returns to the account dashboard and makes no changes to balances.

  • Exc 7a: The backend system times out during processing. The system displays a pending status message and logs the transaction for manual review.

• Success End Condition: The source account balance is reduced, the destination account balance is increased, and a transaction record exists.

• Failed End Condition: No balances are changed, and the user is informed of the failure.

Test Case Table Derived from the Use Case

The use case has five paths, and the table needs six test cases to cover them. The main success scenario takes two, because boundary value analysis puts one test inside the balance (TC-01) and one exactly on it (TC-02). TC-03 and TC-04 cover the two business rules that restrict the amount, and TC-04 needs a higher balance so the limit rule is the one that fires. Each exception gets one test case, TC-05 for the cancellation and TC-06 for the timeout. A fuller suite would add the valid boundary of the daily limit, a transfer of exactly $2,000.

What is the difference between a use case, a test scenario, a test case and a user story?

Each is a separate document written at its own level of detail, and the last column follows the transfer example through all of them.

In Jacobson and Cockburn's terms a scenario is one complete path through a use case. Read a test scenario the same way, as one path described without test data.

Is use case testing still part of ISTQB, and how do agile teams use it?

ISTQB removed use case testing from the Foundation syllabus in 2023 and replaced it with scenario-based testing at Advanced level in 2025.

In the 2018 Foundation syllabus use case testing was taught in section 4.2.5, with a K2 learning objective that asked candidates to explain how to derive test cases from a use case. ISTQB removed it in version 4.0 in April 2023, and the release notes record more focus in chapter 4 on collaboration-based approaches, with new learning objectives for user stories, acceptance criteria and acceptance test-driven development. The current ISTQB Foundation Level syllabus v4.0.1, the September 2024 errata release, lists four commonly used black-box techniques: equivalence partitioning, boundary value analysis, decision table testing and state transition testing.

At Advanced level, the Test Analyst syllabus v4.0 of May 2025 replaced use case testing with a more general objective on scenario-based testing. For finding valuable scenarios it points to user research, user stories, personas and user journey maps, and it teaches two scenario models, activity diagrams and use cases. The term itself is still defined in the ISTQB glossary, as a black-box test technique in which test cases are designed to exercise use case behaviors, and the entry lists no syllabus that uses it.

User stories with acceptance criteria, the agile form of the same thinking, are what the current Foundation syllabus teaches. Use cases helped inspire user stories, as Jacobson, Spence and Kerr wrote in 2016. The most common format for a user story, ISTQB says, is "As a [role], I want [goal to be accomplished], so that I can [resulting business value for the role]", followed by the acceptance criteria. The criteria are the conditions an implementation of the story must meet to be accepted by stakeholders, and they describe both positive and negative scenarios, often in a rule-oriented or scenario-oriented format.

Vervali's advice is to write a full use case anyway for highly complex workflows, financially regulated transactions and features with extensive exception paths.

How do you trace use cases to automated tests in CI/CD?

Traceability, in the ISTQB glossary's definition, is the ability to establish explicit relationships between related work products. The Foundation syllabus asks for it between the test basis elements, test conditions, test cases, test results and defects, and says accurate traceability supports coverage evaluation and shows the impact of a change.

Test management tools hold the testware and the links, and the test analyst updates the traceability with test results, so stakeholders can see how many test cases related to a test condition have passed or failed.

Once the test cases move into an automated suite, behavior-driven development (BDD) can carry the written requirement into the continuous integration pipeline, because its plain-language scenarios are translated automatically into executable tests. Vervali's guide to functional testing tools compares the tools that run automated functional tests.

Cucumber is one tool that does this translation, and its Gherkin reference defines the keywords that structure the tests. The Feature keyword gives a high-level description of a software feature and groups related scenarios. A Rule represents one business rule, and an Example or Scenario is a concrete example illustrating that rule, written as steps that use Given for the initial context, When for an event or action and Then for the expected outcome.

Write one Gherkin scenario for each path through the use case. Put the data variations inside a path into a Scenario Outline, which runs the same scenario multiple times with different combinations of values taken from an Examples section. Selenium, Playwright and Cypress can drive the browser steps, and Vervali's guide to web automation tools compares them.

Tags carry the link back to the use case. In Cucumber they organize features and scenarios and can sit above Feature, Rule, Scenario, Scenario Outline and Examples. Child elements inherit them, so a use case ID tagged on the feature file reaches every scenario inside it. With the ID on every scenario, a red result in the pipeline points straight back to the user goal it belongs to, because Cucumber's reporter plugins show which scenarios passed or failed. Set this tagging convention before the first scenario is written.

An anonymised Vervali engagement: the numbers and what changed

A major Indian airline brought Vervali in to test its booking and check-in platform and to rebuild its front-end architecture. Before the engagement, test coverage on the platform was too thin for the release pace, so customers were reporting issues that testing had not seen.

Vervali built a functional and regression suite around the paths that sell seats and get passengers to the gate, which in use case terms are the paths through two user goals. The team automated the stable journeys and ran cross-browser and real-device testing, with JMeter, BrowserStack, Azure DevOps, Playwright and AWS in the tooling stack. Within two release cycles the engagement delivered 85% test coverage across the booking and check-in workflows, and customer-reported issues dropped by 70%. The rebuilt front-end architecture improved page load time and mobile responsiveness by 40%. Vervali's case studies page carries the rest of its published engagements.

When is use case testing the wrong technique?

Use case testing is mainly end-to-end functional testing from the user's perspective, run against a realistic sequence of actions, so it is the wrong technique for isolating defects deep in the architecture or for covering behaviors that lack user interaction.

The logic inside a single service sits below the actor-to-system interaction a use case describes, and component tests and API testing reach it, with contract tests in the pipeline as described in Vervali's API test automation practices.

Inside the flow, use decision table testing on a step that applies complex business rules, such as calculating a premium, and state transition testing on the steps where the system's reaction to an event depends on its current state.

On non-functional risk, ISTQB's earlier Advanced syllabus noted that use cases are often the basis for performance testing, because they portray realistic usage, and that their behaviors may be assigned to virtual users to create a realistic load. The load test itself is a separate discipline with its own tools, covered on Vervali's performance testing page.

Missing documentation and unknown risks point to exploratory testing, in which tests are designed, executed and evaluated simultaneously while the tester learns about the test object, and which ISTQB calls useful when there are few or inadequate specifications. On a legacy product with no use cases, writing them from scratch might cost more than the testing saves, and exploratory testing can start finding defects straight away. Exploratory testing and use case testing can also run side by side, since ISTQB describes exploratory testing as a complement to the more formal techniques.

If one module of your product has workflows complex enough to need this treatment, Vervali's application testing team offers a free two-week pilot on a single module, with the coverage designed against its paths before any test runs. Start with the contact page.