State transition testing, generated

State transition testing is a black-box technique for anything whose behaviour depends on what has already happened. An order that has shipped cannot be cancelled the way an unpaid one can. A subscription in its grace period behaves differently from one that has lapsed. The same event produces different results depending on the state, and the test design has to account for that.

The model has four parts: states, events that trigger change, transitions from one state to another, and the actions that happen on the way. It can be drawn as a state transition diagram or written as a state table, and both describe exactly the same thing.

All states coverage visits every state at least once. It is the weakest level, because a state can be reached without exercising most of the transitions into and out of it.

Valid transitions coverage, also called 0-switch coverage, exercises every valid transition at least once. It is the usual minimum, and it is what the valid transition tests here provide. All transitions coverage adds every invalid transition: each state and event combination the model does not allow, which should be refused or ignored. The ISTQB Foundation syllabus treats these as the three standard levels.

Two-step sequences, known as 1-switch coverage, test every pair of consecutive transitions. They find defects that depend on how a state was reached, such as a refund that works after a cancellation but not after a return.

Teams test the happy path through a workflow thoroughly, because that is what the requirement describes. The invalid transitions are rarely written down: shipping an unpaid order, refunding a delivered one twice, approving a request that was already rejected. Each is a single API call or a double click away, and each is a real defect when the system accepts it.

The state table makes them visible. Every empty cell is a test: trigger that event in that state, confirm it is refused, and confirm the state did not change. For anything involving money, a refused transition that still has side effects, such as a second refund email, is as serious as one that is accepted.

The hard part of most state transition tests is not the transition but getting to the starting state. To test a refund from a returned order, the order first has to be created, paid, shipped, delivered and returned. Each test here includes the shortest sequence of events from the start state, so the setup is written once, correctly.

If a state has no path from the start, the tool flags it as unreachable. That is almost always a modelling error, or a real defect in the workflow: a state the system can describe but never enter.