Deriving Test Cases from a State Transition Model

Deriving Test Cases from a State Transition Model (ISTQB CTAL-TA): Complete Guide with Exam Tips

Introduction
State transition testing is one of the core behavior-based (black-box) test techniques in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. At this level you are expected to do more than define it. You must be able to analyze a state transition model, derive test cases from it, and calculate or evaluate the coverage those test cases achieve. This guide explains why the technique matters, what it is, how it works step by step, and how to answer exam questions about it with confidence.

1. Why It Is Important
Many systems behave differently depending on their history. The same input can give different results depending on the state the system is in. Typical examples include:
- an ATM that blocks a card after three wrong PINs;
- a login session that times out;
- an order workflow (Created, Paid, Shipped, Delivered, Cancelled);
- embedded controllers, protocols, GUIs with modes, and wizards.

Testing inputs in isolation, as equivalence partitioning does, cannot reveal defects that depend on sequences of events. State transition testing:
- finds defects in event sequencing, missing transitions, wrong target states, incorrect actions or outputs, and unhandled (invalid) events;
- gives measurable coverage criteria, which supports test planning and exit criteria;
- exposes ambiguities in requirements while the model is being built. This is a form of early (static) testing;
- suits Agile user stories and workflow-heavy business processes, where screen flows and status changes matter.

For the Test Analyst, it is a key tool for systematic, risk-based test design of dynamic behavior.

2. What It Is
A state transition model describes a system as a finite set of states and the transitions between them. Its key elements are:
- State: a condition the system is in, such as Idle, Active, or Locked.
- Event (trigger): something that happens, such as an input, a timer, or a message, and may cause a transition.
- Transition: a change from one state to another, or back to the same state (a self-transition), caused by an event.
- Guard condition: a Boolean condition that must be true for the transition to fire, for example [attempts < 3].
- Action (output): what the system does during the transition, such as showing a message or dispensing cash.
- Initial state and optionally final state(s).

Transitions are usually labelled in the form event [guard] / action.

The model can be shown in two ways:
- State transition diagram: a graphical view with states as nodes and transitions as arrows. It shows only valid transitions.
- State transition table: rows are states, columns are events (or state-event pairs), and each cell gives the resulting state and action. The table shows all combinations, including invalid transitions (empty or 'not allowed' cells). This makes it easier to spot missing requirements and to design negative tests.

3. How It Works: Coverage Criteria
The CTAL-TA syllabus (v4.0) focuses on these coverage criteria:

a) All states coverage
Every state is visited at least once. This is the weakest criterion.
Coverage = (states visited / total states) x 100%.

b) Valid transitions coverage (0-switch coverage)
Every valid transition in the model is exercised at least once. This is the most widely used criterion.
Coverage = (valid transitions exercised / total valid transitions) x 100%.
Full valid transitions coverage guarantees full all-states coverage, but not the reverse.

c) All transitions coverage
Every valid transition is exercised, and an attempt is made to execute every invalid transition shown in the state table.
Coverage = (valid and invalid transitions tested / total valid and invalid transitions) x 100%.
Good practice is to test only one invalid transition per test case. Otherwise fault masking can occur, because the system may stop at the first invalid event and later ones are never really tested.
This is the minimum recommended criterion for mission- and safety-critical software.

d) N-switch coverage (extension)
N-switch coverage exercises sequences of transitions:
- 1-switch coverage covers all valid pairs of consecutive transitions (sequences of length 2).
- In general, N-switch covers sequences of N+1 transitions.
Higher N finds sequence-dependent defects but needs many more tests. It appeared in older syllabi and remains useful background knowledge.

Subsumption: All transitions subsumes valid transitions (0-switch), which subsumes all states. 1-switch subsumes 0-switch.

4. Step-by-Step Derivation of Test Cases
Step 1 – Build or analyze the model. Identify states, events, guards, actions, and the initial state. Check for unreachable states, missing transitions, and ambiguous guards.
Step 2 – Create the state transition table. List every state-event combination. Mark the valid ones (target state and action) and the invalid ones.
Step 3 – Choose the coverage criterion based on risk, criticality, and contractual or regulatory needs.
Step 4 – Identify the test conditions. These are the coverage items: the states, the valid transitions, or the invalid state-event pairs.
Step 5 – Design test cases as paths. Each test case normally starts in the initial state and follows a sequence of events. Each path should cover as many still-uncovered items as possible, to minimize the number of tests.
Step 6 – Specify each test case. Include:
- starting state;
- event sequence with input data that satisfies the guards;
- expected actions or outputs;
- expected end state.
For invalid transitions, the expected result is that the event is rejected or ignored and the state stays unchanged, or as specified.
Step 7 – Measure coverage and add tests until the target is reached.

Worked Example
A simplified PIN entry system has these states:
- S1 Waiting for card
- S2 Waiting for PIN
- S3 1st try failed
- S4 2nd try failed
- S5 Access granted
- S6 Card retained

It has these transitions:
- T1: S1 to S2 on card inserted
- T2: S2 to S5 on valid PIN
- T3: S2 to S3 on invalid PIN
- T4: S3 to S5 on valid PIN
- T5: S3 to S4 on invalid PIN
- T6: S4 to S5 on valid PIN
- T7: S4 to S6 on invalid PIN

All states coverage can be reached with two tests:
- TC1: S1, S2, S3, S4, S6 (T1, T3, T5, T7)
- TC2: S1, S2, S5 (T1, T2)

Valid transitions coverage needs every T1 to T7. T2, T4, T6 and T7 all end in final states (S5 or S6), so each needs its own test. The minimum is 4 tests:
- TC1: T1, T2
- TC2: T1, T3, T4
- TC3: T1, T3, T5, T6
- TC4: T1, T3, T5, T7

If only TC1 and TC4 were run, they would cover 5 of 7 valid transitions (T1, T2, T3, T5, T7), which is about 71%.

All transitions coverage adds tests for invalid pairs, such as 'valid PIN' while in S1. Each invalid pair goes in its own test where practical.

5. Common Pitfalls
- Forgetting that a final state ends a test case. You cannot continue a path from a terminal state.
- Counting states instead of transitions, or the reverse.
- Ignoring guard conditions. Two transitions from the same state on the same event with different guards are separate transitions.
- Forgetting self-transitions, which also count as transitions.
- Combining several invalid transitions in one test.
- Assuming the diagram shows invalid transitions. Only the table shows them explicitly.

6. Exam Tips: Answering Questions on Deriving Test Cases from a State Transition Model
Tip 1 – Read the coverage criterion precisely. 'All states', 'valid transitions (0-switch)', 'all transitions', and '1-switch' lead to very different answers. Underline it mentally before you start.

Tip 2 – Count first, then build paths. List and number every transition on scratch paper (T1, T2, ...), including self-loops and guarded alternatives. Then tick each one off as your paths cover it.

Tip 3 – Use final states to find the minimum number of tests. Every transition entering a final state ends a test. So the minimum number of tests for valid transitions coverage is at least the number of transitions into final states. Also check whether each test must start in the initial state; usually it must.

Tip 4 – Use the elimination approach. For 'which set of test cases achieves X coverage' questions, check each option for a missing transition or state. One uncovered item disqualifies that option. Also verify that each listed sequence is actually possible in the model. Distractors often contain impossible transitions.

Tip 5 – Calculate percentages carefully. Coverage = covered items / total items. Watch for questions that give a set of tests and ask what percentage of valid transitions is covered. Count unique transitions only, since repeats do not count twice.

Tip 6 – Remember the subsumption hierarchy. 100% valid transitions coverage implies 100% all-states coverage, but not the other way round. All transitions coverage includes invalid transitions. If an option claims all-states coverage guarantees transition coverage, it is false.

Tip 7 – Handle invalid transitions correctly. These are found in the state table, not the diagram. Expect one invalid transition per test case. The expected result is usually 'event rejected or ignored, state unchanged' unless specified otherwise.

Tip 8 – Respect guards. If a question includes guards such as [balance > 0], the test data must make the guard true for that transition to fire. Distractor answers often break a guard.

Tip 9 – Know the 1-switch calculation. For each state, the number of 1-switch sequences passing through it = (incoming transitions) x (outgoing transitions). Sum this over all states for the total number of 1-switch items.

Tip 10 – Link to defects and context. Some questions are scenario-based, such as 'which technique is best for a workflow with status changes?' Choose state transition testing when behavior depends on history or state. Choose decision tables for combinations of conditions, and use case testing for user-system interactions.

Tip 11 – Manage your time. These are K3/K4 questions that may be worth more points. Sketch the diagram or table quickly, number the transitions, and work methodically rather than by intuition.

Summary
Deriving test cases from a state transition model means turning states, events, guards, and actions into concrete test paths. Those paths must achieve a chosen coverage level: all states, valid transitions (0-switch), all transitions, or N-switch. For the exam:
- know the definitions and the subsumption order;
- count transitions systematically;
- remember that final states end test cases;
- check that every path is feasible;
- compute coverage as unique items covered divided by total items.
Mastering this technique helps you pass CTAL-TA and makes you far more effective at finding sequence-related defects in real systems.