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?
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:
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.
Generating test ideas from state models.
For each state, ask:
For events, ask:
For transitions, ask:
Use multiple representations.
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.
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.
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 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:
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?
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".