State Transition Testing

What it is

Many systems can only be in one state at a time, and move between states in response to events. A bank account is either Open, Frozen, or Closed. A booking is Pending, Confirmed, Cancelled, or Completed. State transition testing ensures all these paths work correctly.

The model has four elements:

• States — the distinct conditions the system can be in.
• Events (triggers) — inputs or actions that cause a transition.
• Transitions — the move from one state to another.
• Actions — what the system does when a transition occurs.

Building the state model

Start with a state diagram (boxes = states, arrows = transitions labelled with event/action). Then convert it to a transition table for easier test case derivation.

Worked example

Online order lifecycle: an order starts as Pending, can be Confirmed, Dispatched, Delivered, or Cancelled.

Coverage criteria

There are three main coverage levels:

• 0-switch (all states) — visit every state at least once. Weakest.
• 1-switch (all transitions) — exercise every valid transition at least once. ISTQB Foundation standard.
• 2-switch (all transition pairs) — every consecutive pair of transitions. Strong but expensive.

Testing invalid transitions

A complete test suite also tests transitions that should not be possible. Try to cancel a delivered order. Try to dispatch a cancelled order. These tests verify the system rejects invalid state changes gracefully — not silently, and not by corrupting data.

ISTQB mapping

NZ example — RealMe identity verification

RealMe is New Zealand’s government identity verification service (used by IRD, NZTA, MSD). A RealMe account moves through states during verification.