In 1936, Alan Turing, the father of modern computer science, invented the machine which he named "a-machine" whereby "a" meant "automatic". As a student or someone fond of computer science, one may come across this system as a "finite state machine" that is still used in building architectural designs and state transition testing. The main idea behind Turing's finite state machine was that we start from one state which is a default state of a machine and as the user interacts with it, we jump onto various states accordingly. This idea is inherited heavily in the type of testing we are here to talk about - state transition testing.
State transition testing is a similar concept but here we twist our design according to the testing methods and paradigms. The result is a high-quality product that can withstand any type of behavior and user input and ultimately bring a positive note to our business or product. In this post that revolves around state transition testing, we will cover the following major headlines:
Table of contents
- What are a state and transition?
- What are events and actions?
- Introduction to State Transition Testing.
- Understanding state transition diagrams.
- Understanding state transition table.
- Importance of state transition testing.
- When to use state transition testing?
What are a state and transition?
Before we jump onto state transition testing, it is first important to understand the components associated with it. The first component we see is "state". In theory, a state is the current stage at which we are standing while operating the software. For instance, you are at a KIOSK machine at the airport and looking to interact with it to print your boarding pass. As soon as you get to the machine and assume the servers and everything else is working perfectly, you will see a default screen asking you to tap on the airline logo on which you are traveling. This is the current state of the machine and since it is the starting point, it is also the default state or the starting state.
Once you click on the logo, you jump to another state that asks for the PNR number. This "jump" is technically called a transition as you move smoothly from state A to state B.
Now since you would have landed in this state no matter which logo you clicked, the situation would not be the same this time. But now you have the possibility of two transitions to make - the first one is you enter a correct PNR and move to the next "success" screen. Else, you enter the wrong PNR and move to the "error" screen as follows:
And this process goes on and on until you reach the end state which could be anything according to the machine and your choices as a user.
What are events and actions?
The other two elements of a state transition testing process are:
- Events
- Actions
Both of them are quite easy to follow.
The events are the process that initiates a transition to another state. For instance, in our KIOSK example above, the event is "entering a PNR number". When this event is completed, it initiates a transition that will take the user to the next state. However, the state depends on the user input.
The actions are the endpoint of the transition. In a way, you can assume that the actions are what will happen when your event and transition have occurred. In our example, the event is "entering the PNR" and considering you entered it correctly, the action is "Correct PNR entered" which will end at the next succeeding stage. You can consider "action" as a result of your input. However, this would be a vague definition but works well theoretically.
Introduction to State Transition Testing
Learning the above definitions involved in state transition testing, we can put them together with respect to the testing phase and construct a definition for state transition testing. When we talk about state transition testing, we are talking about a testing type in which we feed the input and observe the end states or in normal terms, the output achieved. Here, we can also rephrase state transition testing to "observing the start state, transition, and the end state of the system". To achieve this, we need to ensure that for each input, we reach a defined output and the system does not fall into loops. So, it would mean that our system needs to have finite states or our system should be a finite state machine.
State transition testing or state transition technique (as it is also popularly called) is only concerned with initial and final states. Therefore, it becomes a black-box testing technique that is not concerned about "how" things are working under the hood. So, in such a scenario, how do we display our logic and findings to the team members or business partners? The answer to this lies in two things - a state transition diagram and a state transition table.
Understanding state transition diagrams
In the previous section, we brief you a bit about the state transition diagram in a more generic sense. Let's pick that diagram up and mould it according to our KIOSK example. Please note that for simplicity, we will assume that our KIOSK machine is extremely simple with very limited functionality.
So, for our KIOSK machine, our state transition diagram would look as follows:
In the above diagram, there are the following entities:
- States - 7 states as displayed by the red circles.
- Transitions - 11 transitions as displayed by arrows.
As one may observe, even though this is an extremely simple machine with just 7 states (practical KIOSK may have a minimum of 15 or more) there is a lot of traffic on the diagram. As a result, sharing this diagram with someone is necessary but may not be sufficient. If we could, we can write on the top of arrows but this would make the diagram a lot more complex. Therefore, with a state transition diagram that clearly defines states and the transitioning states, we also need to provide a state transition table for better clarity.
Understanding state transition table
The above state transition diagram can be converted to a state transition table as follows:
| State | Input | Next State Pass | Next State Fail |
|---|---|---|---|
| Select Airline | Airline 1 | Airline 1 | Invalid |
| Select Airline | Airline 2 | Airline 2 | Invalid |
| Airline 1 | Select PNR | Enter PNR | Exit Screen |
| Airline 1 | Exit | Exit Screen | Invalid |
| Airline 2 | Select PNR | Enter PNR | Exit Screen |
| Airline 2 | Exit | Exit Screen | Invalid |
| Enter PNR | Confirm Print | Confirm Print | Exit Screen |
| Enter PNR | Exit | Exit Screen | Invalid |
| Confirm Print | Press Print | Print Boarding Pass | Exit Screen |
| Confirm Print | Exit | Exit Screen | Invalid |
| Print Boarding Pass | No Input | Select Airline | Exit Screen |
Here, we define the input we want to give to the state, the next state if the input returns success from the server, and the state where the system would be in case of a failure. This makes our state transitions more descriptive and a good document to share with the team that needs to understand it.
Importance of state transition testing
The main point of discussing the state transition system and the table is to understand what type of meaning this type of testing brings into the organization. While the points are discussed below, I am sure you will have predicated them in the previous section.
- The most important thing about using state transition testing is that we reveal the internal behavior of the system. If this type of testing is done carefully, there would be no surprises from the end-users regarding unsteady states.
- State transition testing also helps the tester identify whether any state of the system is left uncovered or not in the test cases. Any such state can cause fatal issues for our product later on in production.
Apart from it, state transition testing will help you, as a tester, understand the product from its core. This will help you not only get the technical side of the product but also the business side. The more a tester knows these two things, the better tester he becomes.
When to use state transition testing?
State transition testing can be used anywhere as long as the tester is confident about it. However, using it in "non-perfect" scenarios can sometimes lead you to complex testing projects. These scenarios may also not require state transition testing always and can conclude the same goals by other types of testing more simply. Therefore, we have put down a few pointers for the testers to refer to before considering state transition testing for the project.
So, always perform state transition testing when:
- When the application is heavily dependent on events or conditions.
- When events are dependent on each other with absolute strictness.
- When a finite set of input values drives the system.
- When the application is a real-time system as it will ensure high dependency and reliability.
Although, as mentioned above, these are just reference pointers, and the tester can use state transition testing on any system as long as they are confident and not wasting any time of the organization.
Conclusion
State transition testing is a black-box testing technique where we focus on the input given to the system, the state it travels to, and the output we receive from it. It helps us understand how the system works, and its behavior and eliminates any unpredictable results to seep into the end-user. In this post, we learned the foundations of state transition testing, how to efficiently document it, and its importance. I hope this post serves as a reference point for your next projects.
