State-Based Models: States, Events, Guard Conditions and Actions

State-Based Models: States, Events, Guard Conditions and Actions (ISTQB CTAL-TA Guide)

Introduction
State-based models describe how a system behaves over time. A system's response depends on what is happening now and also on what happened before. At the ISTQB Advanced Level Test Analyst (CTAL-TA) level, you are expected to read, build and analyse state transition diagrams and tables. You must also derive test cases from them and judge which coverage criterion a test set achieves. This guide covers why the topic matters, what the elements are, how the technique works, and how to answer exam questions on it.

1. Why State-Based Models Are Important

• History-dependent behaviour: Many systems react differently to the same input depending on their history. Examples include login screens, ATMs, vending machines, workflow engines, embedded controllers, protocols, order lifecycles and user account status. Simple input-output techniques such as equivalence partitioning cannot capture this sequencing.
• Finding sequence defects: State models expose defects in the order of operations. Typical examples are missing transitions, wrong target states, incorrect actions, events accepted when they should be rejected, and guard conditions evaluated wrongly.
• Early defect detection: Building the model during test analysis often reveals ambiguities and gaps in requirements before any code exists. A common finding is 'what happens if event X occurs in state Y?'.
• Measurable coverage: The model gives clear, countable coverage items: states, valid transitions, invalid transitions and transition sequences. Coverage can therefore be measured and reported objectively.
• Exam relevance: State transition testing is a core technique in the CTAL-TA syllabus. Questions regularly ask you to count test cases, identify coverage achieved, or spot invalid transitions from a diagram or table.

2. What It Is: The Core Elements
A state transition model, also called a finite state machine, has the following building blocks.

State

• A condition or situation in which the system can exist and wait for an event.
• Examples: 'Idle', 'Card Inserted', 'PIN Entered', 'Locked', 'Logged In'.
• A model has a finite number of states.
• There is normally one initial state, often shown by a black dot with an arrow. There may be one or more final states.
• In diagrams, states are usually drawn as rounded rectangles or circles.

Event (trigger)

• Something that happens and may cause the system to change state.
• It can be a user input (pressing a button), a system or time event (timeout), or a message from another system.
• Events are instantaneous. The system waits in a state until an event arrives.

Transition

• A change from a source state to a target state, triggered by an event.
• Drawn as an arrow between states.
• A transition can lead back to the same state. This is called a self-transition or loop.

Guard condition

• A Boolean condition, written in square brackets, that must be true for the transition to occur when the event happens.
• Example: Enter PIN [PIN valid] versus Enter PIN [PIN invalid AND attempts < 3].
• Guards allow the same event in the same state to lead to different target states. This keeps the model deterministic, provided the guards are mutually exclusive.
• If the event occurs but no guard is true, the transition does not fire.

Action

• An activity the system performs as a result of a transition, written after a slash.
• Examples: display a message, increment a counter, retain the card, send an email.
• Actions are outputs or side effects, and they are what the tester observes and verifies.
• Some notations (UML) also allow entry, exit and do actions attached to states themselves.

Standard transition label notation
event [guard] / action
Example: Withdraw [balance >= amount] / dispense cash, debit account

3. How It Works: Representations

State transition diagram
This is a graphical view showing states as nodes and transitions as labelled arrows. It is easy to read, but it shows only valid transitions. Invalid transitions are implied by the absence of an arrow.

State transition table
This is a matrix with states as rows and events (optionally combined with guard conditions) as columns. Each cell holds the target state and action, or marks the combination as invalid (for example '-' or 'N/A').

• Its main strength is that it shows every state-event combination. This makes invalid transitions explicit and exposes gaps in the specification.
• Number of cells = number of states x number of events (or event/guard combinations).
• Invalid transitions = total cells minus valid transitions.

Worked example: simple PIN entry
The model has four states:

• S1 Waiting for card
• S2 Waiting for PIN
• S3 Access granted
• S4 Card retained

It has these valid transitions:
T1: S1 -- Insert card / prompt for PIN --> S2
T2: S2 -- Enter PIN [valid] / show menu --> S3
T3: S2 -- Enter PIN [invalid AND tries < 3] / increment tries, show error --> S2
T4: S2 -- Enter PIN [invalid AND tries = 3] / retain card --> S4
T5: S3 -- Eject card / return card --> S1

As a table, the columns are the events 'Insert card', 'Enter PIN' (with its guard variants) and 'Eject card', and the rows are S1 to S4. A cell such as 'S1 + Enter PIN' is invalid, because you cannot enter a PIN without a card. A good negative test checks that the system ignores this event or rejects it gracefully.

4. Coverage Criteria
The CTAL-TA syllabus emphasises the following criteria, listed from weakest to strongest in common usage.

All states coverage

• Every state is visited at least once.
• This is the weakest criterion, and some transitions may never be exercised.
• Coverage = states visited / total states.

Valid transitions coverage (also called 0-switch coverage)

• Every valid transition is exercised at least once.
• This is the most widely used criterion.
• Full valid transitions coverage guarantees all states coverage for reachable states. The reverse is not true.
• Coverage = valid transitions exercised / total valid transitions.

All transitions coverage

• Every valid transition is exercised, and every invalid transition is attempted.
• Invalid transitions are best tested one per test case. This avoids defect masking, where one failure hides another, and because an invalid event may abort the sequence.
• This is the minimum recommended for mission-critical and safety-critical software.

N-switch coverage (switch coverage)

• Covers sequences of N+1 consecutive valid transitions.
• 1-switch coverage exercises every valid pair of consecutive transitions. It finds defects that occur only after specific sequences.
• Higher N values increase the number of test cases rapidly.

Testing guard conditions

• Each guard variant is a separate transition and must be covered separately.
• Choose test data at guard boundaries, for example tries = 2 versus tries = 3.
• Combining with boundary value analysis is good practice. For complex guards, decision-table thinking can also help.

Testing actions

• A test case must check the target state and the actions performed.
• Arriving in the correct state with a missing or wrong action, such as a counter not incremented, is still a failure.

5. Deriving Test Cases: Step by Step

1. Identify states, events, guards and actions from the test basis.
2. Draw the diagram and build the full state table.
3. Select the coverage criterion based on risk.
4. Design test cases as sequences that start from the initial state. Each test case specifies:
   • the starting state
   • the events with input data that satisfies the guards
   • the expected actions
   • the expected resulting states
5. For valid transitions coverage, chain as many transitions as possible into each test case to minimise the number of tests.
6. For invalid transitions, put each one in its own test case. Drive the system to the source state, then fire the invalid event and check that nothing changes or that proper error handling occurs.
7. Calculate and report coverage.

Applying this to the example
One test case can cover T1, T3, T2 and T5:
insert card, wrong PIN, correct PIN, eject card
A second test case covers T4:
insert card, then wrong PIN three times
So 2 test cases achieve 100% valid transitions coverage. The same 2 tests also visit all 4 states, so they achieve all states coverage too.

6. Exam Tips: Answering Questions on State-Based Models: States, Events, Guard Conditions and Actions

• Read the notation carefully: In event [guard] / action, only the event triggers the transition. The guard must be true, and the action is the output. Do not confuse a guard with an event, or an action with a state.
• Count transitions, not arrows with the same label: Two arrows from the same state on the same event, but with different guards, are two different transitions. Each needs its own test.
• Remember self-transitions: A loop back to the same state is a valid transition and counts towards coverage. Candidates frequently forget these.
• Know the coverage hierarchy:
  • All transitions coverage includes valid transitions coverage.
  • Valid transitions coverage includes all states coverage for reachable states.
  • 1-switch coverage includes 0-switch coverage.
  A question may ask which criterion is guaranteed by another.
• Minimum number of test cases questions:
  • For valid transitions coverage, trace paths from the initial state and chain transitions until you reach a final state or a dead end.
  • Every transition into a final state usually forces a new test case, because the sequence ends there.
  • Count carefully. The answer is often the number of distinct paths needed to reach every terminal transition.
• Invalid transitions questions:
  • Compute them as total state-event combinations minus valid transitions.
  • Recall that invalid transitions are tested one per test case.
  • Recall that a state table, not a diagram, makes them visible.
• Coverage percentage questions: Divide items exercised by total items. Check whether the question refers to states, valid transitions or all transitions, because the denominator changes.
• Identify what a test sequence achieves: Given test sequences, tick off visited states and exercised transitions on the diagram, then compare with the totals. Watch out for sequences that are impossible because a guard cannot be true at that point.
• Guards and determinism: If two transitions leave the same state on the same event, their guards should be mutually exclusive. An overlapping or incomplete guard set is a specification defect, and questions may ask you to spot it.
• Expected results include actions: When choosing the best test case or expected result, prefer options that verify both the resulting state and the action.
• Technique selection questions: State transition testing is the right choice when behaviour depends on history or sequence: workflows, modes, protocols, screens and embedded systems. If the scenario is about combinations of conditions with no memory, decision tables fit better. If it is about input ranges, choose equivalence partitioning or boundary value analysis.
• Risk-based choice of criterion: Higher-risk systems justify stronger criteria (all transitions, N-switch). Lower-risk systems may only need valid transitions coverage.
• Eliminate distractors: Wrong options often:
  • count states as transitions
  • ignore guard variants
  • double count a transition used twice in one test
  • claim that all states coverage guarantees all transitions coverage
• Work methodically: Sketch the table or label the transitions T1, T2 and so on on scrap paper before answering. It reduces counting errors under time pressure.

7. Summary

• State-based models capture behaviour where history matters.
• States are where the system waits.
• Events trigger change.
• Guard conditions decide whether, and which, transition fires.
• Actions are the observable outputs of a transition.
• Use diagrams for readability and tables for completeness.
• Choose the coverage level by risk: all states, valid (0-switch), all transitions, or N-switch.
• Verify both target states and actions in every test.

For the exam, master the notation, count carefully (including self-loops and guard variants), and know the coverage hierarchy.