Arunkumar Khannur's Software Testing Knowledge Center

12.7. State Transition Diagram based Test Design

STD based test designing is a model based test case designing. In order to design test cases we use following four steps:
  • Understanding the system
  • Identifying states, inputs and guards
  • Create a state model of the application
  • Generate sequences of test actions
These steps are discussed in following sections.

12.7.1. Understanding the system
In this step, we acquire information and understand intended functionality of the system from different perspectives by involving relevant stake holders and also, analyze its environment, different users and interfaces. This activity becomes more difficult when system is of higher complexity and larger size. As such we can not describe entire system in a model.

12.7.2. Identifying states, inputs and guards
After a basic understanding of the software’s functionality, the modeling process continues with the step that involves identifying the inputs and constructing the model.

In order to identify inputs, we have to enumerate the system inputs which include:
  • Identifying every control in the user interface or other interfaces of the system.
  • Analyzing value domains for each input that include boundaries and illegal values,
  • Analyzing and listing response of the system to the inputs
  • Observe guards which are nothing but conditions under which the inputs can be applied, and how the expected responses change depending on the condition.
  • Identifying different operational modes, i.e. states
With these activities, we arrive at a set of states, inputs and guards

12.7.3. Create a state model of the application
Using identified set of states, inputs and guards we can build initial state model. Here, in the model, we can observe that when the system is in a certain state, a certain set of inputs are available. When inputs are applied and guards fulfilled the system makes a transition to a different state where different inputs are available.

By refining this initial model, and also, by looking at the system from different view points, we can understand more about the purpose and functionality of the system. This will allow us to identify more inputs and states. Also, the model can be hierarchically divided into separate models, describing different levels of functionality.

However, we have to be careful in keeping the complexity of the system to a manageable limit else we may arrive at unbelievably higher number of states and transitions in the system. One technique to address this problem is abstraction where in we restrict ourselves to macro level details by avoiding details as much as possible by combining multiple states or inputs. Another technique is exclusion, where we consider important subsets of the STD and ignore some information in the model.

12.7.4. Generate sequences of test actions
After the model has been created, it’s structural validity should be checked before generating the abstract test suite. Checklist for analyzing that the state machine is complete and consistent enough for implementation testing include:
  • One state is designated as the initial state with outgoing transitions
  • At least one state is designated as a final state with only incoming transitions; if not, the conditions for termination shall be made explicit
  • There are no equivalent states, that is, states for which all possible outbound event sequences result in identical action sequences
  • Every state is reachable from the initial state
  • At least one final state is reachable from all the other states
  • Every defined event and action appears in at least one transition or state
  • Except for the initial and final states, every state has at least one incoming transition and at least one outgoing transition for deterministic machines, the events accepted in a particular state are unique or differentiated by mutually exclusive guard expressions
  • The STD is completely specified: every state/event pair has at least one transition, resulting in a defined state; or there is an explicit specification of an error-handling or exception-handling mechanism for events that are implicitly rejected (with no specified transition)
  • The entire range of truth values (true, false) must be covered by the guard expressions associated with the same event accepted in a particular state
  • The evaluation of a guard expression does not produce any side effects in the implementation under test
  • No action produces side effects that would corrupt or change the resultant state associated with that action
  • A timeout interval (with a recovery mechanism) is specified for each state
  • State, event and action names are unambiguous and meaningful in the context of the application

The above steps ensure that the model has a unique initial state, no duplicate states and that all states are reachable in the model.

Using this model we can generate test cases which are in the form of sequences of inputs, and expected resulting states. In STD, a test case can be any valid path in the model. The kind of paths to choose in the test case depends on the wanted coverage in the model.
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
Skype: arun.isqt