State transition testing | ComplexQA Wiki

State transition testing is a black-box test technique in which test cases are designed to exercise elements of a state transition model. The model describes the states of a test object, the events it reacts to and the transitions between states that the events cause. The technique is used when the response of a system to an input depends not only on the input, but also on what happened before.

State models come from automata theory. In 1978 T. S. Chow published in IEEE Transactions on Software Engineering a method for testing software designs modeled as finite-state machines, and the ISTQB glossary names Chow as the source of the term N-switch coverage. Today the technique is one of the four black-box test techniques of the ISTQB Foundation Level syllabus (version 4.0.1, section 4.2.4). The Advanced Level Test Analyst syllabus (version 4.0, 2025, section 3.2.2) adds N-switch and round-trip coverage. The standard ISO/IEC/IEEE 29119-4:2021 describes the technique in clause 5.2.8 and its coverage measurement in clause 6.2.8.

The problem state transition testing solves

Many objects react to the same input in different ways. A "Cancel" button cancels an order that is waiting for payment, refunds an order that has been paid, and does nothing for an order that has already been shipped. A password that is correct opens the account after one failed attempt and does not open it after three, because the account is locked by then. The input is the same, the result depends on the state.

Techniques that look only at input values do not see this dependency. Equivalence partitioning and decision tables describe one reaction to one combination of inputs. They do not describe sequences: what happens if the order is paid, then cancelled, then the payment event arrives again. Defects of this kind appear in the order of events, not in the values.

A state model makes the dependency explicit. It lists the states, says which events are allowed in each of them and where each event leads. Test cases are then derived as paths through the model, and coverage shows which states and transitions the tests have exercised.

Elements of a state model

A state model consists of a few elements. The table lists them with examples from the order life cycle used below.

Element	Meaning	Example
State	Condition in which the object waits for events	Paid
Event	Occurrence that can cause a transition	ship
Transition	Change from a source state to a target state	Paid to Shipped
Guard condition	Condition that must be true for the transition to fire	payment approved
Action	Behavior performed during the transition	send tracking number
Initial state	State in which the object starts	Pending payment
Final state	State after which the object accepts no events	Delivered, Cancelled

The ISTQB syllabus writes a transition label as event [guard condition] / action. The guard condition and the action are omitted when there are none or when they are not relevant to the tester. Transitions are considered instantaneous. A transition can lead back into the same state: a declined payment leaves the order waiting for payment and shows an error.

Guard conditions split one event into several transitions. The event pay from the state Pending payment leads to Paid when the payment is approved and stays in Pending payment when it is declined. For the tester these are two different transitions, and each needs its own test.

State diagram

A state diagram shows the states as nodes and the valid transitions as arrows labeled with events. The order life cycle of an online shop has five states and six valid transitions:

 start
   |
   v
+-----------------+   pay [declined] / show error
| Pending payment |--------------------------+
|                 |<-------------------------+
+-----------------+
   |          |
   | cancel   | pay [approved] / send receipt
   |          v
   |     +------+
   |     | Paid |----------------------+
   |     +------+                      |
   |          |                        | cancel / refund
   |          | ship / send tracking   |
   |          v                        |
   |     +---------+                   |
   |     | Shipped |                   |
   |     +---------+                   |
   |          |                        |
   |          | deliver                |
   |          v                        |
   |     +-----------+                 |
   |     | Delivered |                 |
   |     +-----------+                 |
   v                                   |
+-----------+                          |
| Cancelled |<-------------------------+
+-----------+

The transitions are numbered for reference in the rest of the article:

No.	Source state	Event [guard] / action	Target state
T1	Pending payment	pay [approved] / send receipt	Paid
T2	Pending payment	pay [declined] / show error	Pending payment
T3	Pending payment	cancel	Cancelled
T4	Paid	cancel / refund	Cancelled
T5	Paid	ship / send tracking	Shipped
T6	Shipped	deliver	Delivered

The diagram shows only what is allowed. It does not show what happens when an event arrives in a state that has no arrow for it, for example cancel for a shipped order.

State table

A state table is a model equivalent to a state diagram. Its rows are states, its columns are events together with guard conditions, and each cell holds the target state and the action. Unlike the diagram, the state table shows the invalid transitions explicitly. The ISTQB syllabus leaves such cells empty; in the table below a dash marks them:

State	pay [approved]	pay [declined]	cancel	ship	deliver
Pending payment	Paid / send receipt	Pending payment / show error	Cancelled	-	-
Paid	-	-	Cancelled / refund	Shipped / send tracking	-
Shipped	-	-	-	-	Delivered
Delivered	-	-	-	-	-
Cancelled	-	-	-	-	-

The table has 25 cells: 6 valid transitions and 19 invalid ones. Building the table forces a decision for every cell. A cell that nobody can fill is a question to the authors of the requirements: should a paid order that is cancelled during packing be refunded, or rejected?

Invalid transitions

An invalid transition is an event that arrives in a state where it is not allowed. The expected result of such a test is defined by the requirements. Usually the object stays in the same state, no action is performed, and the user or the calling system receives an error. Some events are ignored without an error by design, for example a repeated deliver from a courier system. The test checks the state after the event, not only the message.

Invalid transitions are not always reachable through the user interface. A user interface can hide the "Ship" button for an unpaid order while the API behind it still accepts the request. Tests of invalid transitions are therefore also run below the user interface, where the event can be sent directly.

Coverage criteria

The ISTQB syllabus defines three coverage criteria for state transition testing. Each is measured as a percentage: exercised coverage items divided by all coverage items.

Criterion	Coverage items	Order example
All states coverage	States	5 states
Valid transitions coverage (0-switch)	Single valid transitions	6 transitions
All transitions coverage	Valid and invalid transitions of the state table	6 valid and 19 invalid

The criteria form a hierarchy. Full valid transitions coverage guarantees full all states coverage. Full all transitions coverage guarantees both. The syllabus calls valid transitions coverage the most widely used criterion and recommends all transitions coverage as a minimum for mission-critical and safety-critical software.

All states coverage

All states coverage requires every state to be reached at least once. In the order example two test cases are enough: one goes through Pending payment, Paid, Shipped and Delivered, the other cancels the order. The criterion is weak: it can be met without exercising the refund (T4) or the declined payment (T2).

Valid transitions coverage

Valid transitions coverage requires every valid transition to be exercised at least once. It is also called 0-switch coverage. A test case is a sequence of events, and one test case can exercise several transitions. Three test cases cover all six transitions of the example; they are listed in the section on test cases below.

All transitions coverage

All transitions coverage adds every invalid transition of the state table. The syllabus recommends testing one invalid transition per test case. Two invalid events in one test case can cause defect masking: the first defect hides the second. In the example the 19 invalid transitions need at least 19 test cases. The valid transitions fit into their first steps, which bring the order into the state where the invalid event is sent.

N-switch coverage

N-switch coverage is the coverage of sequences of N+1 consecutive valid transitions. Valid transitions coverage is the case N = 0. 1-switch coverage requires every pair of consecutive transitions, where the second starts in the state where the first ends. The order example has six such pairs:

State between	Pairs of transitions
Pending payment	T2 then T1, T2 then T2, T2 then T3
Paid	T1 then T4, T1 then T5
Shipped	T5 then T6

The pair T2 then T2 is two declined payments in a row. It checks that the second attempt is still accepted after the first one fails, which single transitions do not show. According to the Test Analyst syllabus, 0-switch and 1-switch coverage are frequently used in practice, and 2-switch or higher coverage is indicated only for a high risk of failure. The same syllabus defines round-trip coverage: a round trip is a loop that starts and ends in the same state, with no other state occurring twice in it.

Test cases for the order example

The following test cases achieve full valid transitions coverage. Each row is a sequence of events from the initial state Pending payment.

Test case	Events	States passed	Transitions
ST-1	pay [declined], pay [approved], ship, deliver	Pending payment, Pending payment, Paid, Shipped, Delivered	T2, T1, T5, T6
ST-2	cancel	Pending payment, Cancelled	T3
ST-3	pay [approved], cancel	Pending payment, Paid, Cancelled	T1, T4

ST-1 and ST-2 together reach all five states, so they achieve all states coverage. ST-3 adds the refund, the only transition the first two miss. Each test case checks the state and the action after every event: the error message after the declined payment, the receipt, the tracking number, the refund.

Tests of invalid transitions follow the same pattern with one invalid event at the end. For example:

Test case	Events	Expected result
ST-4	pay [approved], ship, cancel	Error; state stays Shipped; no refund
ST-5	ship	Error; state stays Pending payment; no tracking number
ST-6	cancel, pay [approved]	Error; state stays Cancelled; no payment is taken

The test cases are written in the usual form with preconditions, steps and expected results; the structure is described in the article Test case. The guard conditions often hide input partitions: "payment approved" and "payment declined" are the result of card data, amount limits and the response of the payment provider. Choosing values for them is the subject of equivalence partitioning and boundary values.

Visualizing the flow

The diagram and the table are two views of one model, and each shows what the other hides. The diagram shows the flow: the main path from the initial state to the final states, loops and branches. The table shows completeness: every pair of state and event, including the invalid ones.

Test cases can be drawn on the diagram as paths. Marking the path of each test case makes gaps visible: an arrow that no path crosses is a transition without a test. The same check can be made with the transition list: a column per test case and a mark for each transition it exercises.

Larger models use richer notations. The Test Analyst syllabus names extended finite state machines, Harel statecharts and UML state machines. Harel's 1987 paper describes statecharts as state-transition diagrams extended with hierarchy, concurrency and communication. Hierarchy keeps a diagram readable: a state "Active" can contain Paid and Shipped, and one cancel arrow from "Active" stands for several transitions. For test design such a model is flattened back into a table, so that each transition and each invalid cell can be counted.

A state diagram in a specification is often a summary. RFC 9293, which defines TCP, says of its own state diagram that it is only a summary and must not be taken as the total specification. Test cases are derived from the full description of the behavior, not only from the picture.

Where the technique applies

The technique applies to anything whose behavior depends on a history of events. Typical areas:

User interface flows: multi-step forms and wizards, sign-in with locking after a number of failed attempts, sessions that expire.
Protocols: connection handling and message sequences. TCP, as described in RFC 9293, has eleven connection states, from LISTEN and SYN-SENT to TIME-WAIT and CLOSED.
Workflows: life cycles of documents, orders, tickets and defect reports. The states of a defect report are described in the article Defect report.
Embedded and control software: devices with operating modes, where an event allowed in one mode is dangerous in another.

The model has to stay small enough to review. When the number of states grows, the model is split by concern or built with nested states. When the states hide many combinations of conditions, a decision table is used for each state.

State transition testing is often confused with techniques that also produce paths or rules. The table compares them.

Technique	What the model describes	Coverage items	Strength
State transition testing	States, events and transitions	States, transitions, N-switches	Order of events, invalid events
Decision table testing	Combinations of conditions and actions	Feasible columns of the table	Complex rules for one input
Use case testing	Interactions of an actor with the system	Main and alternative scenarios	End-to-end user goals
Equivalence partitioning	Partitions of input values	Partitions	Choice of values

A decision table describes one reaction to a combination of conditions; a state model describes how reactions change over time. They are often used together: the guard conditions of a transition with several conditions are expanded into a decision table, described in decision table testing.

A use case also describes a sequence, but from the point of view of the actor and the goal, not of the object and its states. One use case, such as "buy a product", can pass through several states of the order. Use case testing checks that the goal is reached on each scenario; state transition testing checks that the object reacts correctly to every event in every state, including events the scenarios never send.

Terms

Term	Meaning
State transition testing	Black-box test technique in which test cases are designed to exercise elements of a state transition model
State diagram	Diagram of the states of an object and the valid transitions between them
State table	Table of states and events whose cells hold target states and actions; empty cells are invalid transitions
Guard condition	Condition that must be true for an event to cause a transition
Invalid transition	Event that arrives in a state where the model does not allow it
Valid transitions coverage	Share of valid transitions exercised by the tests; also called 0-switch coverage
All transitions coverage	Share of valid and invalid transitions of the state table exercised or attempted by the tests
N-switch coverage	Coverage of sequences of N+1 consecutive valid transitions
Round trip	Loop that starts and ends in the same state, with no other state occurring twice