State Transition Testing: Diagram, Table, Examples (2026)

Last updated: July 17, 2026 · 11 min read · By Avinash Kamble, reviewed by Priyanka G.

State Transition Testing is the black-box technique for any feature that has modes — a shopping cart moving through empty → active → checkout → paid, an OTP code moving through sent → valid → used → expired, an approval workflow moving through draft → submitted → approved → published. If you skip this technique, you ship the class of bugs where a user re-triggers a state and the system silently corrupts. This guide gives you the diagram, the state table, the coverage levels, and interview-ready examples.

Pair with decision table testing and the black box testing complete guide.

Key takeaways

• Use it whenever the feature has clearly defined modes and legal / illegal transitions.
• Model with a state diagram AND a state table — they catch different mistakes.
• 0-switch coverage = every valid transition once; N-switch coverage = every sequence of N+1 transitions.
• Catches the “illegal transition” bug class that other techniques routinely miss.

State Transition Testing is a black-box technique that models the system as a finite set of states connected by transitions, then designs tests to cover every legal transition (and, ideally, every illegal one). Documented as an experience-based / specification-based technique in the ISTQB Foundation syllabus.

• The feature has clearly defined modes: cart, workflow, session, wallet, subscription, OTP, approval.
• The requirement mentions phrases like “can only be… from…” or “transitions to…”.
• You have caught “wrong state” bugs in production before (double-charging, expired OTP still valid, re-approval loops).
• Compliance requires proof that illegal transitions are blocked.

1. States — the modes the system can be in (e.g. Empty, Active, Checkout, Paid).
2. Transitions — the allowed moves between states (Empty → Active on add-item).
3. Events — what triggers a transition (add-item, remove-item, pay).
4. Actions — what the system does during the transition (update total, send email).

States: Empty, Active, Checkout, Paid.

          add-item          go-to-checkout        pay
 Empty  ─────────▶  Active  ─────────────▶  Checkout  ─────▶  Paid
   ▲                  │                        │
   │  remove-last     │                        │  cancel
   └──────────────────┘                        └──────▶ Active

State table:

• 0-switch (all transitions): exercise every valid transition once. Minimum bar.
• 1-switch (all pairs): exercise every pair of consecutive transitions. Catches bugs where the sequence matters.
• N-switch: exercise every sequence of N+1 transitions. Rarely used outside safety-critical.

Aim for 0-switch coverage plus the top 5 pairwise sequences you know your users actually run.

The biggest ROI of state-transition testing is proving illegal transitions are blocked. From the cart example: what happens if a user posts pay against an already-Paid cart? Or triggers go-to-checkout against an empty one? These are the bugs that leak into production. Add one negative test per illegal cell in your state table.

test('cannot pay for an already-paid cart', async ({ request }) => {
  const cart = await createPaidCart();
  const res = await request.post(`/api/cart/${cart.id}/pay`);
  expect(res.status()).toBe(409);
  const body = await res.json();
  expect(body.error).toMatch(/already paid/i);
});

Store the state table as data, then loop:

const validTransitions = [
  { from: 'Empty',    event: 'add-item',      to: 'Active' },
  { from: 'Active',   event: 'go-to-checkout',to: 'Checkout' },
  { from: 'Checkout', event: 'pay',           to: 'Paid' },
];
for (const t of validTransitions) {
  test(`${t.from} --${t.event}--> ${t.to}`, async () => {
    const cart = await seedCartInState(t.from);
    await fireEvent(cart, t.event);
    expect(await getCartState(cart)).toBe(t.to);
  });
}

Data-driven state loops fit Playwright, Postman, and any modern test runner.

Frequent at 2+ years. Prompts: “Design state transition tests for an ATM”, “Draw the state diagram for an OTP flow”. Rehearse on the AI Mock Interview and prep the whole set on the 3-year Q&A.

Pick one stateful feature in your app. Draw the state diagram in 20 minutes. Fill in the state table. Add one test per legal transition and one per illegal cell. You will find at least one uncovered illegal transition — that's a production incident prevented. Benchmark comp on the QA Salary Guide.