state-transition-test-design

Overview

Per ISTQB CTFL Syllabus v4.0.1 §4.2.4 (opens in new window), "a state diagram models the behavior of a system by showing its possible states and valid state transitions. A transition is initiated by an event, which may be additionally qualified by a guard condition." This skill walks the derivation end to end: stateful spec in, human-readable manual test cases out (event sequences with per-step expected states, not code).

CTFL claims below come from the official v4.0.1 PDF (2024-09-15) fetched from istqb.org on 2026-06-10; the N-switch material comes from the CTAL-TA v4.0 syllabus §3.2.2 (opens in new window) (fetched 2026-06-10). One worked example (account lockout) is carried through every step.

When to use

State transition testing fits wherever "the reaction of the system to an event depends on the current state of the system" - the CTAL-TA syllabus names "embedded systems, dialog-based systems, control systems, or systems that deal with entities and their lifecycles" as canonical stateful systems (CTAL-TA v4.0 §3.2.2 (opens in new window)). In web/product QA that means:

• Lifecycle entities: accounts, orders, subscriptions, tickets, documents with draft/review/published states.
• Workflows: approval chains, payment flows, onboarding.
• UI wizards: multi-step forms where back/skip/cancel behavior depends on the current step.

If behavior is stateless rule logic (same input always gives the same output), use decision-table-test-design instead. For a broad multi-lens first pass over a story, use test-case-ideation-from-story (in the qa-process plugin); this skill is the deep walkthrough of one technique.

Worked example spec (used in every step)

Account lockout. An Active account locks after the 3rd consecutive failed login (a lockout email is sent); a successful login resets the failure counter. An admin can unlock a Locked account (counter resets), suspend an Active account, reinstate a Suspended account, and close an Active, Locked, or Suspended account. Closed is terminal. Locked and Suspended accounts reject all logins.

Step 1 - Identify states, events, transitions, guards

§4.2.4 gives the transition labeling syntax event [guard condition] / action, where "guard conditions and actions can be omitted if they do not exist or are irrelevant for the tester" (CTFL v4.0.1 (opens in new window)).

States (4): Active, Locked, Suspended, Closed.

Events (6, counting guarded variants separately): login-success, login-fail [fails < 3], login-fail [3rd consecutive], admin-unlock, admin-suspend, admin-close. The same raw event (login-fail) splits into two columns because its guard changes the target state; per §4.2.4 the table columns are "events (together with guard conditions if they exist)".

Valid transitions (9):

This table doubles as the state diagram in markdown form: every row is one labeled arrow.

Step 2 - Draw the state table (states x events, invalid cells included)

Per §4.2.4, "a state table is a model equivalent to a state diagram. Its rows represent states, and its columns represent events... Table entries (cells) represent transitions, and contain the target state, as well as the resulting actions, if defined. In contrast to the state diagram, the state table explicitly shows invalid transitions, which are represented by empty cells" (CTFL v4.0.1 (opens in new window)).

Empty cells are marked -- below for readability:

Count: 4 states x 6 event columns = 24 cells; 9 valid transitions, 15 invalid. "Invalid" means the model defines no state change for that event in that state, not that the event cannot physically arrive: a user can type correct credentials into a Locked account (row Locked, column login-success); the system must reject the login and stay Locked. Those cells are exactly where lockout-bypass bugs live.

Step 3 - Choose the coverage level

§4.2.4 defines three criteria (CTFL v4.0.1 (opens in new window)):

Per the same section: "all states coverage is weaker than valid transitions coverage", "valid transitions coverage is the most widely used coverage criterion" and guarantees all states coverage, and "all transitions coverage... should be a minimum requirement for mission and safety-critical software." Coverage for each is the exercised (or attempted) items divided by total items, as a percentage.

Transition pairs (1-switch, Chow). Beyond CTFL, "N-switch coverage applies to valid sequences of N+1 consecutive transitions, also called N-switches (Chow, 1978). 0-switch coverage equals the valid transitions coverage... A 1-switch is a pair of incoming and outgoing transitions at a state. 0- and 1-switch coverage are frequently used in practice"; 100% 2-switch or higher "is only indicated for a high risk of failure due to unexpected sequences of events, as the number of N-switches can grow exponentially with N" (CTAL-TA v4.0 §3.2.2 (opens in new window)).

Practical default: valid-transitions (0-switch) coverage plus targeted invalid-transition tests for the security/abuse-relevant empty cells; escalate to 1-switch pairs around states whose exit behavior depends on how they were entered.

Step 4 - Derive test cases (valid-transitions coverage)

Per §4.2.4, "a test case based on a state diagram or state table is usually represented as a sequence of events" and "one test case may, and usually will, cover several transitions between states" (CTFL v4.0.1 (opens in new window)). Three event sequences cover all 9 valid transitions (9/9 = 100% valid-transitions coverage):

TC-ST-1 (covers t1, t2, t3, t6, t4, t9). Precondition: Active account, failure counter 0, valid + invalid passwords known.

TC-ST-2 (covers t7). Precondition: Active account, counter 0.

TC-ST-3 (covers t8, t5). Preconditions: two Active accounts.

Every step asserts the resulting observable state (admin-panel status, login response, email), never just "action accepted". Expand each into a full runnable script via manual-test-script-author.

Step 5 - Add invalid-transition tests

For all-transitions coverage, §4.2.4 requires that test cases "exercise all the valid transitions and attempt to execute invalid transitions", and warns: "testing only one invalid transition in a single test case helps to avoid defect masking, i.e., a situation in which one defect prevents the detection of another" (CTFL v4.0.1 (opens in new window)). So: one empty cell per test case. The two highest-risk cells here:

TC-INV-1 (Locked + login-success). Precondition: account Locked.

TC-INV-2 (Closed + admin-unlock). Precondition: account Closed.

Full all-transitions coverage means attempting all 15 empty cells (24/24 items). At minimum, cover every empty cell in rows reachable by end users (Locked, Closed) - those are the abuse paths.

Why 1-switch catches what 0-switch misses

TC-ST-1 through TC-ST-3 reach 100% valid-transitions coverage, yet never execute the transition pair (t6 admin-unlock, then t2 login-fail). If the unlock handler forgets to reset the failure counter, one wrong password after an unlock immediately re-locks the account - a real defect that 0-switch coverage cannot see, because t6 and t2 were each exercised, just never consecutively. A 1-switch is exactly this "pair of incoming and outgoing transitions at a state" (CTAL-TA v4.0 §3.2.2 (opens in new window)). Add:

TC-SW-1 (pair t6 then t2). Lock the account (3 failed logins), admin unlocks, then attempt one wrong-password login. Expected: login rejected, account remains Active (counter restarted at 0, not 3).

Anti-patterns

Limitations

• Model quality bounds test quality. The technique only finds defects the state model can express; a missing state in the model is invisible to every coverage level.
• Transitions are modeled as instantaneous (§4.2.4: "the transitions are assumed to be instantaneous"). Races mid-transition (two admins acting at once) need concurrency testing, not this technique.
• N-switch explodes. Per CTAL-TA §3.2.2 the number of N-switches grows exponentially with N; reserve 2-switch+ for high-risk machines.
• Stateless logic does not belong here. Pure input-combination rules go to decision-table-test-design.

References

• ISTQB CTFL Syllabus v4.0.1, §4.2.4 State Transition Testing - istqb.org PDF (opens in new window) (official syllabus, fetched 2026-06-10; CTFL quotes above are from this section).
• ISTQB CTAL-TA Syllabus v4.0, §3.2.2 State Transition Testing - astqb.org PDF (opens in new window) (N-switch / Chow 1978 / round-trip coverage; fetched 2026-06-10). Chow T.S. (1978), "Testing Software Design Modeled by Finite-State Machines", is cited here via the CTAL-TA syllabus.
• ISTQB Glossary terms "state transition testing" and "N-switch coverage" exist at glossary.istqb.org but the site blocks non-browser fetches; cite the syllabus sections above as the stable sources.
• Siblings: decision-table-test-design (stateless rule logic), manual-test-script-author (expands derived cases into runnable scripts).
• Neighbors this skill is distinct from: test-case-ideation-from-story, boundary-value-generator, test-case-anatomy-reference.