Scenario-Based Testing with Activity Diagrams

Scenario-Based Testing with Activity Diagrams (ISTQB CTAL-TA): A Complete Exam Guide

Introduction
Scenario-based testing is one of the behavior-based test techniques in the ISTQB Certified Tester Advanced Level Test Analyst (CTAL-TA) syllabus. The other techniques in that group are CRUD testing and state transition testing. Scenario-based testing focuses on how actors (users or other systems) interact with the test object to achieve a goal. Those interactions are often described as use cases or user stories and modeled visually with UML activity diagrams. The Test Analyst derives test cases from the paths through these diagrams. At exam level this is typically a K3 (apply) topic, so you must be able to work with a diagram and identify or count scenarios, not just define terms.

Why It Is Important
1. Business-relevant testing: Scenarios mirror real end-to-end usage. Testing them confirms the system delivers value to its users, not just that individual functions work.
2. Uncovering flow defects: Many defects hide in the transitions between steps. Examples include a missing error-handling branch, an alternative path that never returns to the main flow, a wrong decision condition, or an incorrect order of actions.
3. Early static testing: Building or reviewing an activity diagram often reveals ambiguities, missing alternatives, unreachable activities and dead ends in requirements before any code exists.
4. Measurable coverage: Each scenario is a coverage item, so progress and thoroughness can be reported objectively.
5. Good fit for acceptance and system testing: The technique fits user acceptance testing and system testing well. It also supports Agile teams where user stories and their acceptance criteria describe flows.

What It Is
A scenario is a sequence of interactions between actors and the test object that leads to an outcome. Scenarios are commonly classified as:
- Main (basic) scenario: the typical, 'happy path' sequence that achieves the goal.
- Alternative scenarios: valid variations that still achieve the goal, or a different acceptable outcome. Example: paying by voucher instead of by card.
- Exception (error) scenarios: situations where something goes wrong and the goal is not achieved. Examples are an invalid input, a timeout or a rejected payment. The system should handle these gracefully.

An activity diagram represents these scenarios graphically. Its key elements are:
- Initial node (filled circle): where the flow starts.
- Action/activity (rounded rectangle): a step performed by an actor or the system.
- Decision node (diamond with one input and several guarded outputs): a branching point. Guards are written as [condition].
- Merge node (diamond with several inputs and one output): where alternative branches rejoin.
- Fork and join (thick bars): the start and end of concurrent (parallel) activities.
- Activity final node (bullseye): the end of the whole activity. A flow final node (circle with X) ends only one flow.
- Swimlanes (partitions): show which actor or component performs each action.
- Control flows (arrows): the order of execution.

How It Works
Step 1 – Analyze the test basis. Study use cases, user stories, business process descriptions or workflow specifications. Identify the actors, the goal, the preconditions and the postconditions.

Step 2 – Model or review the activity diagram. If no diagram exists, the Test Analyst may create one. Check it for correctness and completeness. Ask whether every decision has all possible outcomes, whether every branch reaches a final node, and whether there are actions that cannot be reached.

Step 3 – Identify the coverage items (the scenarios). Each scenario is a path from the initial node to a final node. Two points need care:
- Decisions: each outgoing branch creates additional paths.
- Loops: a loop could generate an infinite number of paths. Testers therefore limit iterations, typically to: skip the loop (0 iterations, if possible), go through it once, and perhaps a typical or maximum number. The exam question normally states the rule to apply. Read it carefully.
- Parallel flows (fork/join): the order inside parallel regions usually does not create new scenarios unless the question states otherwise.

Step 4 – Derive test cases. For each scenario, define the following:
- preconditions
- input data that drives execution down that exact path, satisfying the guard conditions
- expected results and postconditions
One test case may cover one scenario. Depending on the exercise, a minimal set of test cases is chosen to cover all scenarios.

Step 5 – Measure coverage.
Scenario coverage = (number of scenarios exercised / total number of identified scenarios) x 100%
Full coverage means every identified scenario (main, alternative and exception) has been tested at least once.

Worked Example
Consider an online checkout described as follows:
1. The customer reviews the cart.
2. Decision: [voucher entered] goes to Validate voucher; [no voucher] goes directly to Choose payment.
3. Validate voucher has its own decision. [valid] leads to Apply discount, then a merge into Choose payment. [invalid] leads to an Error message, which loops back to step 2. Assume the loop is executed at most once.
4. Choose payment then Pay. Decision: [payment accepted] leads to Confirm order and the final node. [payment rejected] leads to Show failure and the final node.

The voucher part gives the following paths:
(a) no voucher
(b) voucher valid
(c) voucher invalid, then on the second attempt no voucher
(d) voucher invalid, then on the second attempt voucher valid

Each of these combines with payment accepted or payment rejected, giving 4 x 2 = 8 scenarios. The main scenario is (a) with payment accepted. Alternatives include the valid-voucher paths. Exception paths include the rejected payments and the invalid-voucher detours.

If the question instead asks for the minimum number of test cases to cover every branch (transition), the answer is lower. Three test cases can cover all edges: (a)+accepted, (b)+rejected, (c)+accepted. This difference between path/scenario coverage and branch/edge coverage is a classic exam trap.

Strengths and Limitations
Strengths:
- realistic, user-oriented tests
- good at finding integration and flow defects
- easy to communicate to business stakeholders
- supports requirements reviews
Limitations:
- the number of paths can explode with many decisions or loops
- quality depends on how complete and accurate the diagram is
- it does not by itself select data values within a path; combine it with domain testing or boundary value analysis for that
- concurrency may be under-tested

Exam Tips: Answering Questions on Scenario-Based Testing with Activity Diagrams
1. Read the coverage criterion exactly. Decide whether the question asks for all scenarios (paths), all actions, all decision outcomes, or the minimum number of test cases. Each produces a different answer.
2. Apply the loop rule given in the question. Typical wording is 'each loop executed at most once' or 'zero and one iteration'. Never assume unlimited iterations. If no rule is given, the syllabus convention is to limit loops to a small number of iterations.
3. Trace systematically. Start at the initial node and branch at every decision. Write each path down as a short code (for example A-B-D-F) so you neither double-count nor miss any.
4. Multiply independent decisions in sequence, and add branches that are mutually exclusive. Watch for decisions nested inside a branch: they only multiply that branch.
5. Check that every path ends at a final node. A flow final node ends a path too. Dead ends in the diagram may be the defect the question is pointing to.
6. Distinguish scenario types. Questions may ask which path is the main, an alternative or an exception scenario. The main scenario is the most common successful path. Exception scenarios do not achieve the actor's goal.
7. Remember fork/join semantics. Parallel actions are all executed, so they are not alternatives. Do not count them as separate branches.
8. Look for static defects. Some questions ask what a review of the diagram would reveal. Typical findings are a decision missing an outcome (for example, no [else] guard), overlapping guards, unreachable actions, or a loop with no exit.
9. Calculate coverage percentages carefully. If 5 of 8 identified scenarios are executed, coverage is 62.5%. Distractor answers often use the wrong denominator, such as the number of decisions or actions.
10. Eliminate distractors that confuse techniques. State transition testing focuses on states and events. Decision table testing focuses on combinations of conditions. CRUD testing focuses on data entity operations. Scenario-based testing focuses on sequences of interactions from start to end.
11. Manage your time. K3 diagram questions take longer. Sketch the paths on scratch paper, verify the count once, and move on. Come back if time permits.
12. Know the purpose statement. Be ready to recognize that scenario-based testing helps confirm the test object supports real user workflows. It also helps find defects in the handling of alternative and exceptional flows.

Summary
Scenario-based testing with activity diagrams turns use cases and workflows into a visual model. The coverage items are the paths from start to end: main, alternative and exception scenarios, with loops bounded. To succeed in the exam, identify the exact coverage criterion, trace paths methodically, apply the loop rule, and avoid confusing path coverage with branch coverage or with other behavior-based techniques.