I have been looking at different testing techniques and wondered if anyone had some "real world" examples of using state transition diagrams rather than the bog standard clock and light switch ones that are always used. I was also wondering if when using a wizard does each page of the wizard count as a separate state?

  • 1
    There are two questions wrapped up into one here. First is a request for information of other state transition diagrams. Second is a question about the relationship between wizards and the states of a state engine. I think this question should be reworded for the first one to be more on the lines of "What other state transition diagrams are in use for designing software test cases?" The second question should be broken out into it's own question. May 31, 2011 at 16:20
  • Agree with TristaanOgre -- I think there are one or more worthwhile questions here but the current wording is confusing.
    – user246
    May 31, 2011 at 19:26
  • 1
    I don't think I'm reading Teague's question in the same way as you two - to me, the question about the wizard is part of the overall question, it's an attempt to provide an example of a real life example that might be relevant. (And Dale's answer uses it nicely). I do think it could be improved - but I'm not reading it as "What other state transition diagrams are in use" but "How can I apply state transition diagrams to real world testing situations?"
    – testerab
    Jun 1, 2011 at 0:21
  • I agree with @testerab. I think asked on their own, they both are decent questions (both of which, however, I would like to see expanded upon!) But they're also very related, so much so that staying in the same post is still viable. I think if they weren't so tightly coupled we should break it out into two questions.
    – corsiKa
    Jun 1, 2011 at 2:07
  • 1
    Thanks for all of the answers and comments. I will try and be more specific in future when asking a question. A big thank you @testerab your answer and understanding of the question was of great help also @Dale Emery thanks for such a detailed response that has cleared up most of the questions i had about state transition diagrams.
    – Teague
    Jun 6, 2011 at 14:53

5 Answers 5


How I think about state models for testing. A state is the system's readiness to respond in a planned way to each of a set of defined events. You know that a system is in a new state (compared to a moment ago) if:

  • The set of events to which it now responds differs from the set a moment ago.
  • The system now responds to given events differently than it responded to those same events a moment ago.

What counts as a state. What "counts as a separate state" depends not only on the system and its behavior (actual or planned), but also on your purpose for modeling. Your purpose helps you to decide which details to include and which to exclude. If you're trying to test the possible paths through a wizard, then likely you'll want to model each of the pages as a state. On the other hand, if you're trying to test how the wizard validates the user's input, you'll likely not care so much about each of the pages as a separate state.

So: What is your purpose for modeling the states? What are you trying to test? Include states relevant to that purpose.

Note that deciding what to put into the model and what to leave out is always a challenge. If you find your diagram becoming too messy, with states and events at multiple levels of detail (e.g. workflow transitions vs details of error detection and correction), or if you have transition lines crossing all over the place, consider putting the different levels on different diagrams.

Examples to explore. These are relatively simple, so they're easy to practice with. And they're also richer than the average light switch, so they're more instructive.

  • Model the cruise control of an automobile.
  • Fire up PowerPoint, put it into "presentation" mode, and press the B key. Then again. Then the W key. What other keys do interesting things? What are the states involved in displaying the slides?
  • Draw a state model of the life cycle (or possible life cycles) of a defect in your defect tracking system.
  • Model the possible flows of a loan application through a bank's approval process, or an insurance claim through an insurance company's claims process.

Generating test ideas from state models.

For each state, ask:

  • What can I do that might cause the system to change state? What else can I do?
  • What happens if I cause an event that the model doesn't show for this state?
  • What events have I not yet tried in this state?
  • What variables might be involved in this state? What if I vary those?
  • What system resources does the system access while in this state (e.g. database transaction, memory, items from the domain model, files, ...). What if those resources were unavailable, or changed?
  • Can I put the system directly into this state, rather than transitioning the way the model says? (One example: On a web app, save a bookmark partway through some workflow. Complete or abandon the workflow. Click the bookmark. How does the system handle that?)
  • What other states might there be, that are not shown in the model?

For events, ask:

  • From what states have I not yet tried this event?
  • What if I were to do this repeatedly, or rapidly, or slowly, or randomly, or ...?
  • What if I were to do these events in a different order?
  • What if I do this event in a state for which the model shows no response?
  • How could I do this event differently (e.g. different data, different timing, different input mechanism [pasting vs typing, menu selection vs button press vs keyboard shortcut, ...])?
  • What other events might there be, that are not shown in the model?

For transitions, ask:

  • What if I do stuff while the system is making the transition?
  • Can I cause the system to make a transition that the model doesn't show?
  • What transitions haven't I tried yet?

Use multiple representations.

  • Draw a bubbles-and-lines state diagram.
  • Show the same state model as a table. Down the side, list the possible states. Across the top, list the possible states. Each cell represents a transition from the starting state (listed on the side) to an ending state (listed across the top). In each cell, show the event that will cause that transition.
  • Show the same state model as a different table. Down the side, list the possible states. Across the top, list the possible events. Each cell represents the system's response to that event while in that state. In each cell, show the new state that the system enters when that event happens in that starting state.

Compare representations, noting which details each makes easier to see, and which harder. For example, in a bubbles-and-lines diagram, it's easy to see flows, and harder to see all the ways the system might respond to a given event. What other differences do you see?

Given models versus creating your own. The act of constructing a model of actual behavior is a great way to explore a system or feature. Also, models given to you by others are usually models of desired behavior. They may not match actual behavior. Treat every "desired behavior" model as something to be verified.

  • +1 This is such a good answer. I keep re-reading it and thinking "but how'd you pack so much into that few words and make it so clear and straightforward too?"
    – testerab
    Jun 1, 2011 at 0:31
  • 1
    +1 I didn't really understand the question, however, you did answer a question that I didn't even know that I was questioning! Jun 1, 2011 at 1:16
  • I love this answer. Sure, it's a bit of a read, but it's a good read!
    – corsiKa
    Jun 2, 2011 at 22:26

State transition testing is perhaps the most commonly used approach in software testing. Everytime a tester performs an action, takes note of the state, then considers the next possible set of actions they are essentially testing transitions between states.

Sometimes a state transtion diagram is helpful in simplifying complex systems with multiple states and transitions between those states, and can help testers find holes, or help focus testers to important paths.

State transition testing is also the backbone of model based testing.

For a simple example of state transition testing and a simple diagram see http://www.testingmentor.com/imtesty/2011/02/21/state-transition-testing-thinking-in-models/


State Transition Diagrams are a handy tool in some contexts, but I wouldn't refer to them as a "Software Testing Technique".

I don't know what this has to do with a "bog standard clock and light switch".

  • Hi Joe, any chance you could elaborate on why State Transition isn't a testing technique please? I am really under the impression that is a valid technique.
    – DuncN
    Jun 3, 2011 at 10:17
  • DuncN - It's the "Diagrams" that aren't a technique. Diagrams are tools. Jun 6, 2011 at 21:16
  • I think "bog standard clock and light switch" refers to the tendency for text books on testing to use a light switch or digital clock/watch as an example when explaining state transition diagrams.
    – Tom77
    Jun 16, 2011 at 15:16

State transition diagrams can be a pretty handy communication aid when you're trying to understand how the system is meant to work - it helps you to spot transitions you might miss, if you didn't have the different states drawn out on a whiteboard in front of you.

Here's one real-life example. Let's pick an online retailer. We'll look at orders - they're a good example of something that may have several different states, and you might want to test how something moves between those states, and what actions you're allowed to perform on the order when it's in different states.

Here are the states:

  • Security check - some orders will go through a routine security check before the order is placed
  • Order placed - order is on the system and waiting for stock to become available
  • Goods allocated - some or all stock has been allocated to the order
  • Stock warning - some items are out of stock
  • Payment taken - at this stage, you should be able to see a shipping date for each item
  • Payment error - there was a problem taking the payment
  • Pick in Progress - the order's in the warehouse system and the goods are actually being picked off the shelves. Too late to change the order details/shipping address now!
  • Shipping - it's left the warehouse and is on its way to you
  • Invoiced
  • Scheduled for Cancel - cancel request received and acknowledged
  • Cancelled - request now actioned.

There are eleven different states there, and an individual order is not going to go through all of them. You can probably see some sequences that make sense - e.g. Order Placed, Goods Allocated, Payment Taken, Pick In Progress, Shipped. But if you just try to put together lists of sequences, you may well miss transitions you should test that you would have been able to spot easily in a diagram.

The other thing that drawing up a diagram will reveal is gaps in the knowledge you have - for instance, you might start wondering - can I make a cancel request at any stage? Or are there only certain states that I can reach "Scheduled for Cancel" from - maybe I can only cancel the order while there are no goods allocated, or perhaps I can cancel at any stage up to Pick In Progress. If my order is in the Payment Error state - where can I go from there? If I make a successful payment, what state does the order go to? If I don't, where does it go? Is there a time limit?

Try drawing out a state transition diagram from the example given, and see how much you can fill in from what you know now. The bits you don't know enough to fill in, or where the information you've got is ambiguous - those are the questions you'd raise with your business analyst, or product owner.

Does that help?

  • One thing to keep in mind is that sometime "states happen" when you don't want them to. For example, adding items, adding items, going to checkout, ooo wait adding more items. Sometimes, you didn't intend for this to happen, but now you're in a different state. We can call it "returned to shopping from checkout". Our diagram says we should be in "shopping" but because we've messed with the internal state, it may have gone haywire. Finding these "accidental states" can be very difficult; fixing them can be even harder!
    – corsiKa
    Jun 2, 2011 at 22:28
  • Yup - and they can also be a lucrative security loophole for malicious users, if you can manage to use them to bypass e.g. taking a payment.
    – testerab
    Jun 6, 2011 at 19:27

I have used a state transition diagram to test the video player functionality of an application. The functionality is essentially the same as a DVD player. I found it a useful technique for this particular item of functionality.

I haven't, and probably wouldn't use a state transition diagram to test a Wizard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.