angryweasel
Andrew Schiano
brucecrms
herrickspencer
kristianjaeger
Prakash
qingsongyao
ramonarjona
Rob TOne of our goals at Expert Testers is to discuss practical topics that can help every tester do their job better. To this end, my last two articles have been about Decision Table Testing and Being an Effective Spec Reviewer. Admittedly, neither of these topics break new ground. That doesn’t mean, however, most testers have mastered these techniques. In fact, almost 50% of the respondents to our Decision Table poll said they’ve never used one.
Continuing the theme of discussing practical topics, let’s talk about State Transition Diagrams. State Transition Diagrams, or STDs as they’re affectionately called, are effective for documenting functionality and designing test cases. They should be in every testers bag of tricks, along with Decision Tables, Pair-Wise analysis, and acting annoyed at work to appear busy.
STDs show the state a system will move to, based on its current state and other inputs. These words, I understand, mean little until you’ve seen one in action, so let’s get to an example. Since I’m particularly busy (i.e., lazy) today, I’ll use a simple example I found on the web.
Below is a Hotel Reservation STD. Each rectangle, or node, represents the state of the reservation. Each arrow is a transition from one state to the next. The text above the line is the input–the event that caused the state to change. The text below the line is the output–the action the system performs in response to the event.
Pasted from <http://users.csc.calpoly.edu/~jdalbey/SWE/Design/STDexamples.html>
One benefit of State Transition Diagrams is that they describe the behavior of the system in a complete, yet easy-to-read and compact, way. Imagine describing this functionality in sentence format; it would take pages of text to describe it fully. STDs are much simpler to read and understand. For this reason, they can show paths that were missed by PM or Developer, or paths the Tester forgot to test.
I learned this when I was testing Microsoft Forefront Protection for Exchange Server, a product that protects email customers from malware and spam. The product logic for determining when a message would be scanned was complicated; it depended on the server role, several Forefront settings, and whether the message was previously scanned.
The feature spec described this logic in sentence format, and was nearly impossible to follow. I took it upon myself to create a State Transition Diagram to model the logic. I printed it out and stuck it on my office (i.e., cubicle) wall. Not a week went by without a Dev, Tester, or PM stopping by to figure out why their mail wasn’t being scanned as they expected.
If you read my article on Decision Tables (DTs), and I’m sure you didn’t, you may be wondering when to use an STD and when to use a DT. If you’re working on a system where the order of events matter, then use an STD; Decision Tables only work if the order of events doesn’t matter.
Another benefit of STDs is that we can use them to design our test cases. To test a system completely, you’d need to cover all possible paths in the STD. This is often either impractical or impossible.
In our simple example, there are only four paths from start of the STD to the end, but in larger systems there can be too many to cover in a reasonable amount of time. For these systems, you can use multiple STDs for sub-systems rather than trying to create a single STD for the entire system. This will make the STDs easier to read, but will not lower the total number of paths. It’s also common to find loops in an STD, resulting in an infinite number of possible paths.
When covering all paths is impractical, one alternative is to ensure each state (node) is covered by at least one test. This, however, would result in weak coverage. For our hotel booking system, we could test all seven states while leaving some transitions and events completely untested.
Often, the best strategy is to create tests that cover all transitions (the arrows) at least once. This guarantees you will test every state, event, action, and transition. It gives you good coverage in a reasonable amount of tests.
If you’re interested in learning more about STDs (it’s impossible to cover them fully in a short blog article) I highly recommend reading A Practitioner’s Guide to Software Test Design. It’s where I first learned about them.
The next time you’re having trouble describing a feature or designing your tests, give a State Transition Diagram or Decision Table a try. The DTs and STDs never felt so good!
Filed under: Test Planning, Testing Tools, Uncategorized | Tagged: Decision Tables, State Transition Diagrams, Test Planning |
Expert Testers 
Hello Andrew,
I’m making my first STD right now 😉
We have a client service that’s responsible for registering the client with our server. I started this document and I’m starting to realize that I’m mapping everything it does, not just it’s states and I am wondering if I have gotten of track or if state transition diagrams often have more than just the states… For instance, from checking whether or not this service is registered with the server my service can do a couple of different things, one of those things is register with the server. In my STD I have all of the things that it does if it isn’t registered and I’m not sure if I’ve gotten away from the point of a STD….
Cheers,
Josiah
You never forget your first STD 😉
In my opinion, the purpose of the STD (or Test Plan, Decision Table, etc.) is to help you document the feature and design test cases. If adding this information helps you do that, then great. If not, leave it out. The document itself is useless — it’s what you learn from it that matters.
Josiah –
If you have “State X” and you are testing “Action M” and you believe that “State X” could be a valid state when “Action M” happens, then you might want to go ahead and add “State X” to your STD.
It may or may not be necessary to add all the actions that create “State X”. Traversals through an STD that land on the exact same state are theoretically equivalence classes to all transitions that follow. So long as you are not concerned with testing this equivalence (I like to partition my state testing – have one test that checks things like equivalence, another that deals with different things that happen after the state) you can just add the shortest route to getting that state – maybe even just assume in the model that the state exists a priori.
But the other thing to concern yourself with is saliency. For example, assume there is registry keys stored in the system somewhere and it can be in one of three values – so if it is in your STD as result of some action, there are (size of model * 3) states. Assume that there is no reason why “Action M” or any of its following transitions would consume or change that variable. If that variable is the only thing distinguishing the state in question, then there is diminished risk in skipping it in the STD.
Regarding the broad topic –
I find Spec # a very useful tool for constructing and analyzing state models. It is similar to C# in terms of flexibility, but has the domain specific aids on expects of a state modeling tool.
I have not used it for driving test automation. But I did use it one time to figure how many possible ways a bug could occur for a system we were running in production. I mapped out what we understood regarding the fundamental variables and transition rules, and then I created a rule that would conditionally format the boxes in the diagram as red if specific state conditions existed.
I used color because the STD generated by Spec # was huge – printed out it was four feet high and eight feet long and the text was still only about 2 points tall. But with color, one could still stand far away from that printout – or look at it on a screen – and easily draw conclusions like “Everything to the left of this branch is good, everything to the right hits the bug state, and this subset of branches never self-correct”
This really helped because we were then able to target the transition points from good to bad – and discover that out of this massive state diagram, there were only about 5 or so sequences that had unique bugs needing to be fixed to make the problem go away.
[…] is a follow on to Andrew’s article “State-Transition Testing.” If your software can be described using states, you can use monkey automation to test […]
As someone studying software testing at university I was really exited to find this blog, especially considering I’m considering trying to get into software testing when I graduate.
Out of curiosity though how does one actively find negative test cases using a STD considering they aren’t normally used to highlight negative test cases?