Use Case Scenarios: Main Scenario, Extensions and Exceptions (ISTQB CTAL-TA Use Case Testing)
Introduction
Use case testing is one of the behavior-based (black-box) test techniques in the ISTQB Certified Tester Advanced Level Test Analyst (CTAL-TA) syllabus. It derives test cases from use cases, which describe how actors (users or external systems) interact with a system to reach a goal. To apply the technique well, and to score well in the exam, you must understand the three parts of a use case's behavior:
• the main scenario,
• the extensions (alternative flows),
• the exceptions (error flows).
Why It Is Important
• It reflects real usage: Use cases describe how the system is actually used. Tests derived from them are realistic and valuable to the business.
• It finds integration and process defects: Use cases span several steps and components, so they expose defects in workflows, handoffs and business processes that unit-level techniques miss.
• Defects hide away from the happy path: The main scenario is usually well understood and well coded. Extensions and exceptions are where developers most often forget conditions, mishandle errors or leave the system in an inconsistent state.
• It provides measurable coverage: The syllabus defines coverage in terms of scenarios exercised. This gives Test Analysts a clear, objective measure of test completeness.
• It supports acceptance testing: Use case tests are widely used in system and acceptance testing, because stakeholders can easily read and validate them.
• It is heavily examined: Use case testing appears in K3 (apply) and K2 (understand) questions. You may be asked to identify scenarios, count the test cases needed, or judge coverage.
What It Is
A use case is a specification of interactions between an actor and a system (the subject) that produces a result of value to the actor. Each use case has these parts:
• Actor(s): human users, external systems or devices.
• Subject: the system or component under consideration.
• Preconditions: what must be true before the use case starts.
• Postconditions: the observable results and final state once the use case completes.
• Behaviors: the flows of interaction, described below.
1. Main Scenario (Basic Flow / Happy Path)
The main scenario is the most common, expected sequence of steps. The actor reaches the goal without any deviation or problem. It is the 'normal' path through the use case.
Example (ATM Withdraw Cash):
1. Customer inserts card.
2. System requests PIN.
3. Customer enters a valid PIN.
4. System displays the menu.
5. Customer selects withdrawal and enters an amount.
6. System dispenses cash, returns the card and prints a receipt.
2. Extensions (Alternative Scenarios / Alternative Flows)
Extensions are valid variations from the main scenario. They branch off at a particular step and still lead to the goal, or to another acceptable outcome. They are not errors. They are legitimate alternative ways the interaction can proceed.
Examples:
• 5a. The customer selects a preset 'fast cash' amount instead of typing one.
• 6a. The customer chooses not to print a receipt.
3. Exceptions (Error Flows / Exceptional Behavior)
Exceptions describe what happens when something goes wrong. Typical triggers are an invalid input, a resource that is unavailable, or a business rule that is violated. They usually stop the actor from achieving the goal, or require recovery or error handling.
Examples:
• 3a. Invalid PIN entered. The system displays an error and allows a retry. After three failed attempts, the card is retained.
• 5b. Insufficient funds. The system displays a message and returns to the menu.
• 6b. The ATM has no cash. The system cancels the transaction and returns the card.
Note on terminology: The CTAL-TA syllabus (v4.0) talks about the main behavior plus alternative behaviors and exception/error behaviors. Other sources group alternatives and errors together as 'extensions'. In the exam, read the scenario carefully. An 'extension' usually means a deviation from the main path, and an 'exception' usually means error handling.
How It Works: Deriving Test Cases
Step 1: Analyze the use case. Identify the actors, preconditions, postconditions, main scenario steps, and every extension and exception, together with the step where each one branches.
Step 2: Identify scenarios (paths). Each unique path through the use case is a scenario:
• one path for the main scenario,
• one path for each extension,
• one path for each exception.
Step 3: Design test cases. Create at least one test case per scenario. Each test case should:
• set up the preconditions,
• execute the steps of that path,
• supply the triggering condition for the branch (for example, an invalid PIN),
• check the expected result and the postconditions.
Step 4: Add test data. Combine the scenarios with other techniques. Equivalence partitioning and boundary value analysis can supply data values within each step (for example, withdrawal amounts at the limits).
Step 5: Measure coverage.
• Use case coverage = (number of use case behaviors tested ÷ total number of use case behaviors) × 100%.
• Behaviors include the main behavior, the alternative behaviors and the error behaviors.
• Full coverage requires at least one test for every behavior.
Worked Example
Suppose a use case has the following:
• 1 main scenario,
• 2 extensions (5a, 6a),
• 3 exceptions (3a, 5b, 6b).
The minimum number of test cases for 100% scenario coverage is 1 + 2 + 3 = 6. If only the main scenario and the 3 exceptions are tested, coverage is 4/6, which is about 67%.
Some flows contain loops, such as 'retry PIN up to three times'. Testers may add tests for different iteration counts, guided by risk. The minimum coverage count, however, normally treats each flow as one scenario unless the question says otherwise.
Additional Considerations for Test Analysts
• Defects found: Use case testing typically reveals:
– missing or incorrect handling of alternative and error flows,
– incorrect postconditions,
– problems in actor-system communication,
– defects in the use case specification itself, such as missing exceptions or ambiguous steps.
• Reviewing the use cases: Test Analysts should check that the use case is complete. Has every likely error been considered? Are the preconditions realistic? Missing extensions are a specification defect.
• Granularity: Use cases can be written at business level or system level. Tests should match that level.
• Includes and extends: Use cases can include other use cases ('include' relationships) or be extended by them ('extend' relationships). Testers should consider how these related use cases interact.
• Risk-based prioritization: When time is limited, the main scenario is usually tested first, because it is the most frequently used. High-risk exceptions, such as payment failures, should follow closely.
Exam Tips: Answering Questions on Use Case Scenarios: Main Scenario, Extensions and Exceptions
1. Count the paths carefully. For minimum-test-case questions, add 1 (main) + the number of alternative flows + the number of exception flows. Check whether the question asks for 'minimum' or 'full' coverage.
2. Distinguish alternatives from errors. Ask whether the deviation still reaches a valid outcome. If yes, it is an alternative (extension). If it handles a problem or failure, it is an exception.
3. Look at the branch step. Labels such as 3a and 5b tell you where a branch starts. A test for 5b must first execute steps 1 to 4 of the main scenario, then follow the 5b branch.
4. Do not double count. Some extensions rejoin the main flow. Each one is still a separate scenario, but you do not need a separate test for the shared remainder.
5. Watch for nested branches. If an exception itself has a sub-alternative (for example, 3a1, retry succeeds, and 3a2, card retained), each sub-branch may be its own scenario. Count them if the question lists them explicitly.
6. Remember the purpose. Questions may ask which technique is best for finding defects in process flows or user interactions. Use case testing is the answer, rather than decision tables or state transition testing.
7. Know the coverage formula. Coverage = behaviors exercised ÷ total behaviors. Practise converting the result to a percentage quickly.
8. Check the preconditions and postconditions. Exam answers may include options that ignore setting up the preconditions, or that skip verifying the final state. A correct test case does both.
9. Eliminate distractors. Wrong answers often:
– test only the main scenario,
– confuse an exception with a boundary value,
– claim that use case testing gives code coverage. It does not, because it is a black-box technique.
10. Read the K-level cue. K2 questions test understanding, for example 'which statement is true about extensions'. K3 questions give a use case and ask you to derive the test cases or calculate coverage. Allocate your time accordingly.
11. Use the syllabus wording. When options differ slightly, prefer the one using ISTQB terms: 'main behavior', 'alternative behavior', 'error behavior', and 'use case coverage'.
12. Combine techniques when asked. If a question asks how to test the data within a step (for example, a withdrawal amount), the best answer usually combines use case testing with equivalence partitioning or boundary value analysis.
Summary
A use case describes:
• a main scenario (the happy path),
• extensions (valid alternative paths),
• exceptions (error-handling paths).
Use case testing derives at least one test per scenario, verifies the preconditions and postconditions, and measures coverage as the proportion of behaviors exercised. For the exam, identify each branch precisely, classify it correctly, count scenarios without double counting, and apply the coverage formula confidently.
