What is State Transition Testing and State Transition Diagram? Explained with examples.
In our last article, we saw ‘Cause and effect graph’ test case writing technique. Today let’s move to next dynamic test case writing method – State transition technique.
Note – The test design techniques mentioned here may seem difficult but once you get hold of it, it becomes very easy to implement and re-use, increasing productivity and test coverage.
State transition testing is a black-box testing technique, which can be applied to test ‘finite state machines’.
A ‘Finite state machine (FSM)’ is a system which will be in different discrete states (like “ready”, “not ready”, “open”, “closed”,…) depending on the inputs or stimuli.
The discrete states that the system ends up with, depends on the rules of transition of the system. That is, if a system gives a different output for the same input, depending on its earlier state, is a finite state system.
Further, if every transaction is tested in the system, it is called a “0-switch” coverage. If testing covers 2 pairs of valid transactions, then it is “1-switch” coverage. And so on.
This document explores expanding this testing concept to bigger applications, which are not FSMs as a whole, but some of their components are, so as to adopt its unique feature of ‘statefulness’ and transition rules, resulting in many advantages.
What You Will Learn:
What is State Transition Testing Technique?
State transition technique is a dynamic testing technique, which is used when the system is defined in terms of a finite number of states and the transitions between the states are governed by the rules of the system.
Or in other words, this technique is used when features of a system are represented as states which transform into another state. The transformations are determined by the rules of the software. The pictorial representation can be shown as:
So here we see that an entity transitions from State 1 to State 2 because of some input condition, which leads to an event and results in an action and finally gives the output.
To explain it with an example:
You visit an ATM and withdraw $1000. You get your cash. Now you run out of balance and make exactly the same request of withdrawing $1000. This time ATM refuses to give you the money because of insufficient balance. So here the transition, which caused the change in state is the earlier withdrawal
State Transition Testing Example in Software Testing
In the practical scenario, testers are normally given the state transition diagrams and we are required to interpret it.
These diagrams are either given by the Business Analysts or a stakeholder and we use these diagrams to determine our test cases.
Let’s consider the below situation:
Software name – Manage_display_changes
Specifications – The software responds to input requests to change display mode for a time display device.
The display mode can be set to one of the four values:
- Two corresponding to displaying either the time or date.
- The other two when altering either the time or the date.
The different states are as follows:
Change Mode (CM)
Activation of this shall cause the display mode to move between “display time (T)” and “display date (D)”.
If the display mode is set to T or D, then a “reset” shall cause the display mode to be set to “alter time (AT)” or “alter date (AD)” modes.
Time Set (TS)
Activation of this shall cause the display mode to return to T from AT.
Date Set (DS)
Activation of this shall cause the display mode to return to D from AD.
State transition diagram
Now, let’s move to interpret it:
1) Various states are:
- Display Time(S1),
- Change Time(S3),
- Display Date(S2) and
- Change Date (S4).
2) Various Inputs are:
- Change Mode(CM),
- Reset (R),
- Time Set(TS),
- Date Set(DS).
3) Various Outputs are:
- Alter Time(AT),
- Display Time(T),
- Display Date(D),
- Alter Date (AD).
4) Changed States are:
- Display Time(S1),
- Change Time (S3),
- Display Date (S2) and
- Change Date (S4).
Write all the start state. For this, take one state at a time and see how many arrows are coming out from it.
- For State S1, there are two arrows coming out of it. One arrow is going to state S3 and another arrow is going to state S2.
- For State S2 – There are 2 arrows. One is going to State S1 and other going to S4
- For State S3 – Only 1 arrow is coming out of it, going to state S1
- For State S4 – Only 1 arrow is coming out of it, going to state S2
Let’s put this on our table:
Since for state S1 and S2, there are two arrows coming out, we have written it twice.
For each state, write down their final state.
- For state S1 – The final states are S2 and S3
- For State S2 – The final states are S1 and S4
- For State S3 – Final state is S1
- For State S4 – Final State is S2
Put this on the table as output / resultant state.
For each start state and its corresponding finish state, write down the input and output conditions
– For state S1 to go to state S2, the input is Change Mode (CM) and output is Display Date(D) shown below:
In a similar way, write down the Input conditions and its output for all the states as follows:
Now add the test case ID for each test shown below:
Now let’s convert it to formal test cases:
(Click image to enlarge)
In this way, all the remaining test cases can be derived. I assume the other attributes of the test cases like preconditions, severity, priority, environment, build etc. are also included in the test case.
Summarizing the steps once again:
- Identify the initial states and their final state based on the lines/arrows that are coming out of the initial state
- For each initial state, find out the input condition and the output result
- Mark each set as a separate test case.
More Examples of State Transition Technique
Here is one more example of State Transition Testing technique in bigger software applications.
‘Stateful Functional Testing’ approach can be used to test specific parts or components of the application, with the characteristic of a Finite State Machine (FSM).
Steps in implementation:
1. The first step in implementing the ‘Stateful Functional Testing’ is to identify different components/parts of the application that can be categorized as FSMs. The inputs, states, and outputs are carefully tracked for each of these FSMs.
2. The next step would be to develop test cases for these FSMs based on transition rules, inputs, outputs and transition states.
3. The third step would be to integrate the testing of these components with other interfacing components for validating the application end to end.
This can be explained by means an example of an application named as “House Project”, which tracks the construction of a house, with various application components like approval of architecture of the house, registration of the plot and house, selection of the building contractor, approval of housing loan, etc.
We shall consider testing of one FSM component of the “House Project” application: Approval of the Housing Loan.
Housing Loan Approval Application (HLA)
The HLA application will be run by an independent Loan Processing User, who processes the loan application. The different steps in the processing of the application are detailed below:
1.1.1 Step 1: Collection of documents
The first step is the collection of relevant documents for applying for the loan as mentioned in the table below. They are the ‘conditions’ for a successful application. The applicant collects the required documents and applies for the home loan. The Loan Processing User acknowledges the receiving of the documents and transitions the state of the Loan Application (that is the state of the HLA Application component) to “Applied” state.
Table 1: List of Documents
1.1.2 Step 2: Loan Assessment
At this stage, the lender assesses the Loan Application to determine whether it meets his credit requirements. The supporting documents are verified at this time.
Table 2: Criticality of Documents
The documents required for the assessment, that is the “conditions “which need to be validated at this stage, are validated. Each condition has a criticality attached to it (mentioned as ‘Y’ in the table above). Once all the required critical conditions are satisfied, the application moves to the state “Confirmed” – that is the HLA application component is in the “Confirmed” state.
Point to note:
#1: This principle brings in a structure and objectivity to the test conditions and “state” definitions of the system.
Also, not all the “conditions” for validating the system are critical for it to reach this “Confirmed” state. In the table above, 4 conditions are marked as “Not Critical” for the application to reach the “Confirmed” state.
#2: Number of validations can be optimally reduced, depending on the risk or criticality of the rules required for each state. This will significantly reduce the time required for test execution, and at the same time not compromising on Quality of testing.
#3: This is not only useful for testing the individual components, but also for testing the system end to end.
#4: Also, very useful while creating regression test suites.
So, at this stage, it is a 0-switch type of testing. But later stages of approval can be 1-switch or 2-switch types of validations for that stage. For example, “Marriage Certificate” may not be too relevant at this stage, but in the later stages of approval when the risk of the applicant to pay the EMI is being considered, the marriage certificate may become relevant – that is, if the spouse is employed too, it reduces the risk, and if not employed, it increases the risk.
#5: The above principle can be used for expanding the test conditions depending on the requirement of the component at that stage.
1.1.3 Step 3: Conditional Approval
The current state of the application is “Confirmed”. The lender would give ‘Conditional approval” for the loan process to move forward. Further validations are required for moving the HLA application to the state “Approved”.
1.1.4 Step 4: Approval
Critical validations are conducted at this stage:
1. Assessment by the Lenders Mortgage Insurance (LMI): this would involve 2-switch or more validations for the property’s genuineness.
2. The Lender may demand information which was not given during the “Confirmation” stage.
Once the above conditions are satisfied, the application moves to “Approved” state. The Final authority of the approval process may cross-check the credibility of the Loan applicant by asking for more details, or may not ask if the Applicant’s other documents are conclusive. That is, more inputs from different components of the main application would be required to prove the validity.
#6: In other words, more validations may be required (or reduced) for the transition to a different state depending on the input conditions to the component from other components of the application.
The diagram below depicts the approval process. (Click on image to enlarge)
Risks and Challenges
- For large applications, deep application knowledge is essential to break the application into different logical components to enable categorization as FSMs and regular components. This might require costly time from SMEs.
- Not all applications would have the feasibility of this kind of FSM categorization.
- Since FSM components interact with regular components in the application, inputs to FSMs from different components require careful planning and execution.
Testing an application with the concept of “Stateful Functional Testing” can give Testing Organizations a unique Test Approach for testing complex applications, which would increase test execution productivity without compromising on test coverage.
State Transition testing is a unique test approach for testing complex applications, which would increase test execution productivity without compromising on test coverage.
About the authors: This article is written by STH authors Shilpa C. and Ramesh R.