Free tool
State transition test generator
Paste a state diagram and get its state table, what each coverage criterion asks for, and the test cases that meet it — including the events each state should refuse.
Start from an example
Syntax
From --> To : event [guard] / action, as in a Mermaid state diagram; the guard and action are optional. [*] --> State marks the start, State --> [*] an end. Paste a Mermaid stateDiagram as it is.
- All states
- 6
- coverage items
- Valid transitions (0-switch)
- 12
- coverage items
- All transitions
- 72
- coverage items
State table · an empty cell is an invalid transition
| State | log in [right username and password] | log in [wrong username or password] | open cart | log out | continue shopping | checkout [cart not empty] | continue [details complete] | continue [a field empty] | back to cart | cancel | place order | back to products |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Login · start | Products | Login | – | – | – | – | – | – | – | – | – | – |
| Products | – | – | Cart | Login | – | – | – | – | – | – | – | – |
| Cart | – | – | – | – | Products | Your details | – | – | – | – | – | – |
| Your details | – | – | – | – | – | – | Overview | Your details | Cart | – | – | – |
| Overview | – | – | – | – | – | – | – | – | – | Cart | Complete | – |
| Complete | – | – | – | – | – | – | – | – | – | – | – | Products |
1 test case, 17 steps, each starting in Login.
ST-V01 · ends in Products
- log in (set up: right username and password) → Products
- open cart → Cart
- continue shopping → Products
- log out → Login
- log in (set up: wrong username or password) → Login, and show error
- log in (set up: right username and password) → Products
- open cart → Cart
- checkout (set up: cart not empty) → Your details
- continue (set up: details complete) → Overview
- cancel → Cart
- checkout (set up: cart not empty) → Your details
- continue (set up: a field empty) → Your details, and show error
- back to cart → Cart
- checkout (set up: cart not empty) → Your details
- continue (set up: details complete) → Overview
- place order → Complete, and empty the cart
- back to products → Products
What it counts, and how
The three criteria are the ones in the ISTQB Foundation Level syllabus (version 4.0, section 4.2.4), and the counts are its coverage items:
- All states: every state is a coverage item. It is the weakest of the three, because a set of tests can visit every state and still skip most of the ways between them.
- Valid transitions, also called 0-switch coverage: every arrow in the diagram. The syllabus calls it the most widely used criterion.
- All transitions: every cell of the state table, so the valid transitions plus every event a state should refuse. A guarded event counts as its own column, as the syllabus describes. Each invalid event gets a test case of its own, reached by the shortest path and tried last: “testing only one invalid transition in a single test case helps to avoid fault masking”.
The cases are built greedily: take an untested transition from where you are, otherwise walk the shortest way to the nearest one. That covers everything reachable, in few cases, but isn’t promised to be the fewest steps possible. States that no path reaches are reported instead of silently skipped — usually a transition is missing from the diagram.
Guards are shown, not worked out
“checkout [cart not empty]” only happens when the cart has something in it. The tool can’t know what your data looks like, so a step that takes a guarded transition says what to set up first. The same event with two different guards leads two ways without being ambiguous; the same event without guards leading to two states is an error, because the system couldn’t know which to do.
The practice shop example is checked against the shop
The first example describes this site’s practice shop. Every case the tool generates for it, valid and invalid, runs against the real shop in our end-to-end tests, so the example can’t drift from what it describes. One simplification: the Cart and Log out links in the shop’s header work from every signed-in page, and the example has them on Products only, to keep the table readable.
Running those tests also found something no state table would list: a signed-in shopper can type the address of the order overview and skip the details form entirely. What that means, and how the other techniques apply to the same checkout, is in black-box test design techniques on one real checkout.