State Transition Testing Technique and State Transition Diagram with Examples

Learn what is State Transition Testing and How to use the State Transition Diagram:

In our last article, we saw the ‘Cause and Effect graph’ test case writing technique. Today let’s move to the next dynamic test case writing method – State Transition technique.

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 ‘being stateful’ and transition rules, resulting in many advantages.

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 that 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, depending on the rules of the transition of the system. That is, if a system gives a different output for the same input, depending on its earlier state, then it is a finite state system.

Further, if every transaction is tested in the system, it is called “0-switch” coverage. If testing covers 2 pairs of valid transactions, then it is “1-switch” coverage, and so on.

What Is The 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 that transform into one another. 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 that results in 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 Definition

Having understood what State Transition is, we can now arrive at a more meaningful definition for State Transition testing. So, it is a kind of black-box testing in which the tester has to examine the behavior of AUT (Application Under Test) against various input conditions given in a sequence.

The behavior of the system is recorded for both positive and negative test values.

When to use State Transition Testing?

State Transition testing can be employed in the following situations:

• When the application under test is a real-time system with different states and transitions encompassed.
• When the application is dependent upon the event/values/conditions of the past.
• When the sequence of events needs to be tested.
• When the application needs to be tested against a finite set of input values.

When not to use State Transition Testing?

You should not rely upon State Transition testing in the following situations:

• When testing is not required for sequential input combinations.
• When different functionalities of the application are required to be tested (more like Exploratory testing).

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 them.

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 correspond 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)”.
• Reset (R): 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:
Here:

#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) The Changed States are:

• Display Time(S1),
• Change Time (S3),
• Display Date (S2) and
• Change Date (S4).

Step 1: Write all of the start states.  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.

Step -2: For each state, write down their final transitioned states.

• For state S1 – The final states are S2 and S3
• For State S2 – The final states are S1 and S4
• For State S3 – The final state is S1
• For State S4 – Final State is S2

Put this on the table as an Output/Resultant state.

Step 3: 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:

Step 4:

Now add the test case ID for each test shown below:

Now let’s convert it to formal test cases:

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 the State Transition Testing technique in bigger software applications.

Description:

‘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.

For Example,

We shall consider testing 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 them to 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 the “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 latter 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:

• Assessment by the Lenders Mortgage Insurance (LMI): this would involve 2-switch or more validations for the property’s genuineness.
• The Lender may demand information which was not given during the “Confirmation” stage.

Once the above conditions are satisfied, the application moves to the “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. 

Figure 1: Loan Approval Process

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.

Advantages of State Transition testing

• Under this technique, by using a pictorial or tabular representation of system behavior, the tester becomes familiar with the application design and feels easy to cover & design the tests effectively and efficiently.
• The unplanned or invalid states of the system get also covered by using this technique.
• Using the State Transition diagram, it’s easy to verify if all the conditions are covered.

Disadvantages of State Transition testing

• This technique can’t be used for nonfinite state systems.
• Defining all possible states for large and complex systems is a quite cumbersome task.

Conclusion

State Transition testing is a helpful approach when different system transitions are required to be tested for finite-state systems.

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.

The limitation of this technique is that it can’t be used until and unless the system under test has only finite states.