Software Testing State Transition Testing

Some software remembers what happened before. A door lock behaves differently after three wrong codes. A bank account behaves differently once the card is blocked. The same input can produce different results, depending on the current state. State transition testing models this memory and checks every path through it.

Core Ideas

• State: a condition of the system at a moment in time, such as Logged Out or Locked
• Event: an action or input that triggers a change, such as entering a wrong password
• Transition: the move from one state to another
• Action: the output that the system produces during a transition

Everyday Example: A Traffic Light

        timer           timer           timer
  RED --------> GREEN --------> YELLOW --------> RED

The timer event produces different results in each state. Red turns to green, green turns to yellow, and yellow turns to red. A tester needs to check all three transitions.

State Diagram: Login With Lockout

  +-----------+  wrong 1   +----------+  wrong 2   +----------+  wrong 3   +--------+
  |  START    |----------->| 1 FAIL   |----------->| 2 FAILS  |----------->| LOCKED |
  +-----------+            +----------+            +----------+            +--------+
       |                        |                       |                       |
       | correct                | correct               | correct               | wait 30 min
       v                        v                       v                       v
  +-----------------------------------------------------------+          back to START
  |                       LOGGED IN                           |
  +-----------------------------------------------------------+

State Transition Table

A table shows every state against every event, including combinations that the system should reject.

Current State	Correct Password	Wrong Password
Start	Logged In	1 Fail
1 Fail	Logged In	2 Fails
2 Fails	Logged In	Locked
Locked	Locked (rejected)	Locked
Logged In	Not applicable	Not applicable

Designing Test Cases

Valid Transitions

Each arrow in the diagram needs at least one test. Tester sends the event in the correct state and checks the next state and the output.

Invalid Transitions

Cells marked "rejected" or "not applicable" represent illegal moves. A tester tries them to confirm that the system refuses them safely. A locked account must reject a correct password until the wait time ends.

Sequences of Transitions

Real users string events together. A path test follows a sequence such as Start, 1 Fail, 2 Fails, Locked, and back to Start after the wait time.

Coverage Levels

Level	Meaning
All states	Every state appears in at least one test
All transitions	Every valid arrow executes at least once
Invalid transitions	Every forbidden state-event pair gets tried
N-switch paths	Chains of several transitions run in order

Second Example: Order Tracking

  PLACED --> PAID --> PACKED --> SHIPPED --> DELIVERED
     |         |
     +---------+--> CANCELLED

Testers verify that a shipped order cannot move back to Placed, that a cancelled order cannot ship, and that cancellation works only before packing. Each rule corresponds to a transition or a blocked event.

Where the Technique Fits

• Login and session handling
• Workflow and approval systems
• ATM and payment flows
• Embedded devices such as washing machines and elevators
• Game characters and user interface modes

Strengths and Limits

The technique exposes hidden states and impossible paths that ordinary input testing overlooks. Diagrams grow messy in systems with dozens of states, so teams split large models into smaller ones. The technique complements decision tables, which handle combinations of inputs without history.

Practice Exercise

Draw the states of a video player: Stopped, Playing, Paused, and Buffering. List the events: Play, Pause, Stop, and Network Slow. Fill a transition table and write one test for each valid and invalid cell.

Tips for Drawing Good State Diagrams

Name each state with a noun or adjective, such as Locked or Paid, and name each event with a verb, such as Submit or Cancel. Keep one diagram per feature so the picture stays readable. Ask the analyst to confirm every arrow, because testers often discover missing rules while drawing. A missing arrow usually signals an undefined behavior that developers must clarify before coding continues.