When developing software for machines and applications, each aspect of the software’s functionality needs to be tested. The software engineers need to understand how the software functions internally, with consideration of the inputs and outputs that are needed for the software to function effectively.
For businesses reliant on software for their employees or customers, such testing is paramount. Where the relevant personnel is available, this can be done in-house via team task management when delegating to the appropriate members of the IT team.
Where nobody is qualified, or if there are skill gaps, it is necessary to use an external software testing outsourcing firm to ensure best practices are used. This will alleviate the possibility of mistakes being made in the testing process, some of which could cause the software designers a slew of problems that later need to be rectified.
A variety of testing techniques can be employed, depending on the software and the machine in question. For “finite-state” systems (FSM) – the systems that depend upon a limited number of predetermined sequences, “state transition testing” is particularly effective. In this guide, we’ll take a closer look at this form of testing and where it might be useful.
What Is State Transition Testing?
As you can probably guess by the phrasing, “state transition testing” refers to the testing of various states within a particular system. It’s a black-box testing technique in which changes made via input conditions cause transitional states in the application being tested. Testers will consider each facet of the application and record how it behaves according to positive and negative input test values.
Many applications rely on state transition testing, including those that we use in our everyday lives. Login pages are a common part of our online existence and this is indicated by the diagram below. The tester might use such a diagram during testing when considering the various inputs the user might use as they attempt to access an application’s homepage.
The inputs are based on the passwords the user will enter when using the application. When entering the correct password on the first, second, or third attempts, they’re redirected to where they want to be: the homepage. When the password is entered incorrectly, a message will be displayed, such as “try again”, which allows for a second or third attempt to enter the password.
Entering the incorrect password on the third attempt would redirect the user to a page stating the words “account locked”. In this example, the login password is the input and the outcomes of each combination are the transitory states. The sequence of events varies, depending on whether or not the user entered the correct password or not.
As the diagram demonstrates, state transition testing involves mapping out the scenarios that are expected when using the application. It shows how a particular update will lead first to a transitional state and then the eventual output within the system.
Let’s relate state transition testing to an ATM. The ATM goes through a number of transitional states, depending on the inputs of the user. Should they enter the right PIN, the user will end up at the “Access Granted” state.
If they enter the wrong PIN, they will pass to another state whereby they’ll be given a second chance. If they enter the wrong PIN again, they will reach the “third chance” state. If they then enter the PIN incorrectly again, another state arises, typically one that indicates that their account has been blocked. You can understand this in relation to the diagram below. We previously used it as an example in an article covering the comparison of test design methods.
In relation to both examples given, software testing is essential. If bugs exist, the user could get to the homepage despite using the wrong password and the person at the ATM could withdraw cash, despite entering the wrong PIN. The reverse could also be true, as a person could be locked out of an account despite entering the correct details.
To determine no problems exist, the software engineer would have to employ state transition testing. As such, they would map out each sequence or pathway and then take the necessary steps to ensure the correct outcomes happen for the user.
Automation tools can be used within the testing process so not everything has to be conducted manually. Take this into consideration when determining when to automate your testing for your business applications.
When Is It Right to Use State Transition Testing?
Instances when state transition testing can be recommended:
- When the tester is testing an application for a finite set of input values.
- When the tester is testing the sequence of events that should occur within the application.
- When the system being tested is dependant on conditions of the past.
- When the application encompasses different states and transitions.
Instances when state transition testing shouldn’t be relied upon:
- When sequential input conditions are not being tested.
- When more complex functionalities within the application need to be tested.
As you can now understand, state transition testing has its place but it is not always recommended. It is best used when trying to ensure a finite system responds correctly to expected conditions. Using tables, graphs, and other diagrams, the tester will have a birds-eye view of how the application should work during the testing process.
The diagrams we used for login and ATM processes are fairly simple. More intricate graphs and tables should be used for more complex applications.
However, when it comes to more complex applications, a broader form of testing, such as exploratory testing, is preferential. Other forms of testing should also be used for infinite-state systems.
State transition testing works well with certain finite systems, such as those we have discussed here. It does not work effectively when software systems need an exploratory approach, such as those that are particularly complex.
Consider these points when determining the testing needed for the applications you are designing.