Systems with memory can only be tested by thinking in states — not just inputs and outputs
A login form that locks after 3 failed attempts behaves differently depending on its history. After 0 failures, a wrong password shows an error. After 2 failures, a wrong password locks the account. The same input produces different outputs depending on the current state.
State transition testing models systems where the current state determines how inputs are processed. It is the only technique that systematically tests what happens when the system is in each possible state — and what happens when invalid transitions are attempted.
// example: amazon — order lifecycle
State Transition Testing — CTFL 4.0.1
Key concepts
- State — a condition the system can be in at a point in time (e.g., Locked, Unlocked, Processing)
- Transition — a change from one state to another, triggered by an event
- Event — the trigger that causes a transition (e.g., "user enters correct password")
- Guard condition — a condition that must be true for the transition to occur
- Action — what the system does when a transition occurs
Representations
State diagram — visual representation with circles (states) and arrows (transitions labelled with events/actions).
State table — tabular representation showing all states, all events, and the resulting next state and action for each combination. Also shows invalid transitions explicitly.
Coverage criteria
- All states coverage — every state is visited at least once
- All transitions coverage — every valid transition is exercised at least once (stronger)
- All transition pairs coverage — every pair of consecutive transitions is tested (strongest)
// tip: Exam Tip: All transitions coverage (testing every valid transition at least once) subsumes all states coverage. If you test all transitions, you automatically visit all states. The exam will ask which coverage criterion is stronger — all transitions coverage is stronger than all states coverage. Also remember: invalid transitions (events that should be rejected in a given state) must be tested too.
Step-by-Step: Login Attempt State Machine
Scenario: A login system has these states: Unlocked (0 failures), Warning (1–2 failures), Locked (3+ failures). Wrong password increments failures; correct password resets.
| Current State | Event | Next State | Action |
|---|---|---|---|
| Unlocked (0 fails) | Correct password | Unlocked (0 fails) | Grant access, reset counter |
| Unlocked (0 fails) | Wrong password | Warning (1 fail) | Show error, increment counter |
| Warning (1–2 fails) | Correct password | Unlocked (0 fails) | Grant access, reset counter |
| Warning (1–2 fails) | Wrong password (fail 2) | Warning (2 fails) | Show warning, increment counter |
| Warning (2 fails) | Wrong password (fail 3) | Locked | Lock account, notify user |
| Locked | Correct password | Locked | Reject — account locked |
| Locked | Admin reset | Unlocked (0 fails) | Unlock, reset counter |
Invalid transition to test: Locked state + correct password — system should reject, not grant access. This is a common defect point.
State Transition Diagram
// login state machine — tap a transition or press play
FROM
Unlocked
EVENT
Wrong password
ACTION
Show error, increment counter
TO
Warning
// tap a transition to animate it
7 shown// coverage criteria — tap to compare
// exam tip
All transitions coverage subsumes all states coverage — testing every valid transition automatically visits every state. Transition pairs is the strongest criterion.
// exam trap
Testing only valid transitions is insufficient. CTFL requires testing invalid transitions too — toggle "Show invalid" above to see the example.
State Transition Coverage Criteria Compared
| Coverage Criterion | What is Tested | Strength | Test Cases Needed |
|---|---|---|---|
| All states | Every state is visited at least once | Weakest | Minimum — one path visiting each state |
| All valid transitions | Every valid transition is exercised at least once | Medium — subsumes all states | At least one test per transition |
| All invalid transitions | Every event that should be rejected in each state | Complements valid transitions | One test per invalid combination |
| All transition pairs | Every sequence of two consecutive transitions | Strongest | Highest — may require many tests |
// warning: Exam Trap: Testing only valid transitions is insufficient. CTFL explicitly states that invalid transitions (events that should not cause a transition in a given state) must also be tested. A system that accepts an invalid transition — for example, allowing a "Locked" account to log in with correct credentials — is defective. If your test suite never tries invalid transitions, it will not find these defects.
Exam Practice Questions
// ctfl 4.0.1 style — select an answer to reveal explanation