4.5 State Transition Testing

Core Idea and Elements

State transition testing is a black-box technique for systems whose response to an event depends on the current state. The hallmark is that the same event yields different outcomes in different states — pressing 'play' does one thing when paused and nothing when already playing.

The model has five elements:

• State — a condition or mode the system holds while waiting for events (e.g. Logged Out, Logged In, Locked).
• Event — a trigger that may cause a change (e.g. enter PIN, time-out).
• Transition — a movement from one state to another (or back to the same state) caused by an event.
• Guard (guard condition) — a condition that must be true for the transition to fire (e.g. attempts < 3).
• Action — an effect produced when the transition occurs (e.g. display balance).

The model is captured as a state transition diagram (bubbles for states, arrows for transitions) or a state table (a grid of every state × every event). The diagram is easier to read; the table is more rigorous because it forces you to consider every state/event pair, including the ones that should do nothing.

A Worked Example: ATM Card Lock

An ATM PIN entry has three states: Idle, PIN Entered, and Card Locked. The relevant events are correct PIN, wrong PIN, and 3rd wrong PIN.

A state diagram would show Idle looping on 'wrong PIN' and arrowing to Card Locked on the third attempt, with no arrow out of Card Locked. The state table additionally exposes the invalid transitions — for instance, what happens if a 'correct PIN' event arrives while in Card Locked? It should be blocked. These blank or negative cells are exactly where state-dependent defects hide, which is why the table form is valued for thorough testing.

Coverage: 0-Switch and Beyond

The CTFL Foundation level focuses on all-transitions coverage, also called 0-switch coverage (or single-transition coverage). It requires that every valid transition is exercised at least once:

Transition coverage % = (valid transitions exercised
                       ÷ total valid transitions) × 100

If the model has 9 valid transitions and your tests trigger 6, transition coverage is 6 ÷ 9 ≈ 67%. Achieving 100% transition coverage automatically achieves all-states coverage (every state visited), but the reverse is not true — you can visit every state without exercising every transition, so all-states coverage is the weaker criterion.

Key exam points:

• Invalid transitions matter. A robust test set includes attempts to fire events that should be blocked in the current state; the syllabus stresses that these negative tests often reveal serious defects.
• The technique fits workflows, sessions, account lifecycles, device modes, and protocols — anything with memory of where it has been.
• 'N-switch' coverage (exercising sequences of N+1 transitions) is a higher-rigour extension, but CTFL Foundation centres on 0-switch. The thing usually counted for coverage is the transition, not the state or the event.

Guards, Actions, and Applying the Technique

Two elements turn a simple state model into a realistic one, and both appear in exam questions:

• A guard (guard condition) gates a transition: the same event in the same state may or may not cause the transition depending on a condition. In the ATM model, 'wrong PIN' keeps the machine in Idle while attempts < 3, but the third wrong PIN (guard: attempts = 3) transitions to Card Locked. The guard is why one event can lead to two different next states.
• An action is the effect produced as a transition fires — show menu, retain card, increment counter. Actions are what the user or system observes, and they are part of what each test verifies.

A four-step procedure

1. Identify the states (modes the system rests in) and the events that can occur.
2. For each state/event pair, determine the next state, any guard, and the action — record this as a state diagram and a state table.
3. Design tests that exercise every valid transition (0-switch coverage), choosing data that satisfies the guards.
4. Add negative tests for invalid transitions — events that should be ignored or rejected in a given state.

What it is good for, and the traps

State transition testing fits anything with memory of where it has been: login/session flows, order and account lifecycles, media-player and device modes, traffic-light and vending-machine controllers, and communication protocols. Exam traps to watch: (1) all-states coverage is weaker than all-transitions coverage — visiting every state does not exercise every transition; (2) the coverage item at Foundation level is the transition, so count transitions, not states or events; (3) invalid transitions are first-class tests, not an afterthought, because blocked-event handling is a frequent source of real defects.

Master reading a state table — most state-transition exam questions hand you one and ask how many transitions, which transitions are invalid, or what the next state is for a given state/event/guard combination.