Are state transition diagrams a good software testing technique

Question

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?

Answer 1

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.

Answer 2

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/

Answer 3

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".

Answer 4

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?

Answer 5

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.