State transition testing primarily focuses on
- all the states of the software under test
- all the transitions to and from the states
What is meant by the states and transitions in a software under test?
Determining states are often most difficult part of state transition testing. Suppose we are testing a user interface with various screens. Here these different screens can be considered as states.
What causes the software transition from one state to other?
Events cause the transition from one state to other.
For example, consider a login event. There are two possibilities.
One login event with valid username/password combination and other with invalid username/password combination. Both will result in different transitions. The login event with valid username/password combination will have a transition to the home page with a welcome message. Another will have a transition to an Error page / Forget password page.
State transition testing is applicable to any software that has defined states and has events that will cause transitions between states.
This is commonly used in embedded software testing.However, this can be applied to application software as well.
How to track various state transitions in a software under test?
There are mainly two ways by which we can achieve this.
- State transition diagrams
- State transition table
Let’s look at the representation of these two using an example.
In the above diagram, states are represented as boxes and transitions are represented as arrows.
Each transition is labeled with the event that triggers the transition (above the dividing line) and the effect (below the dividing line).
Having this diagram handy, we could easily identify all the valid transitions and represent the same in the form of a table.
This can easily translate into test cases.
When it comes to test cases, we need to consider the Event as input and Effect as Expected Output.
When it comes to coverage, test case needs to visit every possible state and transition at least once.
Consider the transition T1 in the above State Transition table. This represents a single transition from S1 —-> S2. This kind of transition is known as 0-Switch.
Similarly, a sequence of two consecutive transitions called as 1- switch. (E.g. S1(TV Off)—>S2(TV Stand By)—>S3(TV Play)).
The above example state transition table represents 0-switch. The Same way we can construct 1-switch state transition table from the state transition diagram presented at the beginning. Sometimes the 1-switch transitions can uncover some failures which 0-switch coverage would have missed.
This representation is known as N-1 switch coverage, where N represents the number of transitions that will be traversed.
It is also possible that to revisit certain stages which are already visited in a sequence of transitions. Also, there is Round-trip coverage where we cover all the transitions from starting point and return to the starting point at the end.
(E.g. S1(TV Off)—>S2(TV Stand By)—>S3(TV Play)—>S1(TV Off)).
Be sure to include even invalid transitions also in the state transition table while testing.
Strength & Weakness:
State transition diagram/table gives us a clear picture of all the testing paths that must exercise at least once during testing. Nevertheless analyzing the possible paths through the states help eliminate some repetitive tests and also helps encourage thinking toward transactions in detail.
This test technique can’t be applicable if the software doesn’t have clear states or lot more transitions from each state. For example in certain websites, it is possible for the user to navigate as many transitions from a single screen. Representing all these transitions through diagram/ table and simulating every possible sequence of transitions is often a tedious task.
Now, lets look into the ISTQB definitions for some of the concepts discussed in this blog post.
State Transition Testing (N-switch testing) :
A black-box test design technique in which test cases are designed to execute valid and invalid state transitions.
State diagram :
A diagram that depicts the states that a component or system can assume, and shows the events or circumstances that cause and/or result from a change from one state to another.
A grid showing the resulting transitions for each state combined with each possible event, showing both valid and invalid transitions.
A transition between two states of a component or system.
Hopefully, you understood these definitions from the explanations and example diagrams.
Did you get a chance to apply this technique in your project test scenarios? If so, feel free to share it in the comments below.