State Transition Testing Technique and State Transition Diagram with Examples

Discover the State Transition Testing Technique and How to utilize the State Transition Diagram:

In our prior article, we explored the ‘Cause and Effect graph’ test case writing technique. Today, we’ll delve into the next dynamic test case writing method – State Transition technique.

This documentation examines the extension of this testing concept to larger applications that may not be entire FSMs but have certain components that are, in order to leverage its distinctive ‘stateful’ and transition rules features, resulting in numerous benefits.

State Transition Testing

State Transition testing is a Black-box testing method that can be employed to test ‘Finite State Machines’.

A ‘Finite State Machine (FSM)’ is a system that can exist in different discrete states (such as “ready”, “not ready”, “open”, “closed”,…) based on the inputs or stimuli it receives.

The specific states that the system ends up in depend on the transition rules of the system. In other words, if a system produces different outputs for the same input, based on its previous state, then it is a finite state system.

Furthermore, if all the transitions in the system are tested, it is known as “0-switch” coverage. If the testing covers 2 pairs of valid transitions, it is known as “1-switch” coverage, and so on.

Understanding the State Transition Testing Technique

The state transition technique is a dynamic testing approach used when the system is defined in terms of a finite number of states and the transitions between these states are governed by the rules of the system.

In other words, this technique is used when the features of a system are represented as states that transition into one another. These transitions are determined by the software’s rules. The representation can be visually depicted as:

Here, an entity transitions from State 1 to State 2 due to some input condition, which triggers an event and results in an action, ultimately leading to an output.

To illustrate with an example:

Imagine visiting an ATM and withdraw $1000. You obtain your cash. However, when you attempt to withdraw another $1000, the ATM declines the transaction due to insufficient funds. In this case, the transition that caused the state change was the previous withdrawal.

Definition of State Transition Testing

Now that we understand what State Transition means, we can establish a more meaningful definition for State Transition testing. It is a type of black-box testing in which the tester examines the behavior of the Application Under Test (AUT) against various input conditions presented in a sequence.

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

When to Use State Transition Testing?

State Transition testing can be employed in the following scenarios:

• When the application under test is a real-time system with multiple states and transitions.
• When the application relies on past events, values, or conditions.
• When testing the sequence of events is necessary.
• When the application needs to be tested with a finite set of input values.

When Not to Use State Transition Testing?

State Transition testing should be avoided in the following scenarios:

• When testing sequential input combinations is unnecessary.
• When testing different functionalities of the application is required (similar to exploratory testing).

Example of State Transition Testing in Software Testing

In practical scenarios, testers are typically provided with State Transition diagrams and are required to interpret them.

These diagrams may be provided by Business Analysts or stakeholders, and testers utilize them to derive test cases.

Let’s consider the following scenario:

Software name: Manage_display_changes
Specifications: The software responds to input requests for changing the display mode of 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 corresponding to altering either the time or the date.

The different states are as follows:

• Change Mode (CM): Activating this changes the display mode from “display time (T)” to “display date (D)” or vice versa.
• Reset (R): If the display mode is set to T or D, a “reset” changes it to “alter time (AT)” or “alter date (AD)” mode respectively.
• Time Set (TS): Activating this changes the display mode back to T from AT.
• Date Set (DS): Activating this changes the display mode back to D from AD.

State Transition diagram

Now, let’s interpret it:
The diagram includes:

#1) States:

• Display Time (S1)
• Change Time (S3)
• Display Date (S2)
• Change Date (S4)

#2) Inputs:

• Change Mode (CM)
• Reset (R)
• Time Set (TS)
• Date Set (DS)

#3) Outputs:

• Alter Time (AT)
• Display Time (T)
• Display Date (D)
• Alter Date (AD)

#4) Transitions:

• Display Time (S1)
• Change Time (S3)
• Display Date (S2)
• Change Date (S4)

Step 1: Identify the start states. Examine the number of outgoing arrows for each state.

• For State S1, there are two outgoing arrows leading to State S3 and State S2.
• For State S2, there are also two outgoing arrows, leading to State S1 and State S4.
• For State S3, there is only one outgoing arrow leading to State S1.
• For State S4, there is also only one outgoing arrow leading to State S2.

Represent this in a table:

Since State S1 and S2 have two outgoing arrows, they are listed twice.

Step 2: For each start state, record their final 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, the final state is S2.

Record these as the Output/Resultant states.

Step 3: For each start state and its corresponding final state, document the input and output conditions.

– To transition from state S1 to state S2, the input is Change Mode (CM) and the output is Display Date (D):

Similarly, document the input conditions and outputs for all the states:

Step 4:

Finally, add the test case ID for each test:

Now, let’s convert it into formal test cases:

In this manner, the remaining test cases can be derived. It is assumed that other test case attributes such as 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 states based on the outgoing arrows from the initial states.
• For each initial state, determine the input conditions and the output results.
• Assign a separate test case ID to each set.

Additional Examples of State Transition Technique

Here is another example of the State Transition Testing technique applied in larger software applications.

Description:

The ‘Stateful Functional Testing’ approach can be used to test specific parts or components of an application that possess the characteristics of a Finite State Machine (FSM).

Implementation Steps:

#1) The first step in implementing ‘Stateful Functional Testing’ is to identify different components/parts of the application that can be categorized as FSMs. Carefully track the inputs, states, and outputs for each of these FSMs.

#2) The next step is to develop test cases for these FSMs based on transition rules, inputs, outputs, and transition states.

#3) Finally, integrate the testing of these components with other interfacing components to validate the application end-to-end.

This can be demonstrated with an example of an application called “House Project” that tracks the construction of a house, with various application components such as house architecture approval, plot and house registration, selection of the building contractor, and housing loan approval, etc.

For example,

Let’s consider testing one FSM component of the “House Project” application: Approval of the Housing Loan.

Housing Loan Approval Application (HLA)

The HLA application is operated by a Loan Processing User who processes the loan application. The different steps in the application processing are outlined below:

1.1.1 Step 1: Collection of Documents

The first step involves collecting the necessary documents for the loan application as listed in the table below. These documents are the “conditions” for a successful application. The applicant gathers the required documents and submits them for the home loan.

The Loan Processing User acknowledges the receipt of the documents and transitions the state of the Loan Application (i.e., the state of the HLA Application component) to the “Applied” state.

Table 1: Document List

1.1.2 Step 2: Loan Assessment

At this stage, the lender assesses the loan application to determine whether it meets the credit requirements. The supporting documents are verified during this process.

Table 2: Document Criticality

During the assessment, the required documents (i.e., the “conditions”) for validation are checked. Each condition is assigned a criticality level (marked as ‘Y’ in the table above). Once all the critical conditions are satisfied, the application transitions to the “Confirmed” state, indicating that the HLA application component is in the “Confirmed” state.

Note:

#1) This principle brings structure and objectivity to the test conditions and system “State” definitions.

In addition, not all “conditions” for validating the system are critical for reaching the “Confirmed” state. In the table above, 4 conditions are marked as “Not Critical” for the application to reach the “Confirmed” state.

#2) The number of validations can be optimized based on the risk or criticality of the rules required for each state. This significantly reduces the execution time for testing without compromising on quality.

#3)This approach is not only useful for testing individual components but also for testing the entire system end-to-end.

#4)It is also very useful for creating regression test suites.

Thus, at this stage, it is a 0-switch type of testing. However, later stages of approval may require 1-switch or 2-switch types of validations.

For example, “Marriage Certificate” may not be too relevant at this stage, but in later stages of approval, when assessing the applicant’s ability to pay the EMI, the marriage certificate becomes relevant. If the spouse is employed, it reduces the risk, while if the spouse is unemployed, it increases the risk.

#5) This principle can be applied to expand the test conditions depending on the requirements of the component at that stage.

1.1.3 Step 3: Conditional Approval

The current state of the application is “Confirmed”. The lender gives conditional approval for the loan process to proceed. Additional validations are required to transition the HLA application to the “Approved” state.

1.1.4 Step 4: Approval

At this stage, critical validations are conducted:

• Assessment by the Lenders Mortgage Insurance (LMI): This involves 2-switch or more validations for validating the genuineness of the property.
• The Lender may request additional information that was not provided during the “Confirmation” stage.

Once the above conditions are satisfied, the application moves to the “Approved” state. The final approval authority may conduct additional checks on the applicant’s credibility by requesting more details, or they may not require additional information if the applicant’s other documents are conclusive. In other words, more inputs from different components of the main application are necessary to validate the loan application’s credibility.

#6) In other words, more validations may be required (or reduced) for transitioning to a different state depending on the input conditions to the component from other components of the application.

The following diagram illustrates the approval process:

Figure 1: Loan Approval Process

Risks And Challenges

• For large applications, in-depth knowledge of the application is essential to break it down into logical components and categorize them as FSMs and regular components, which may require significant time from Subject Matter Experts (SMEs).
• Not all applications may be feasible for this type of FSM categorization.
• Since FSM components interact with regular components in the application, careful planning and execution of inputs to FSMs from different components are required.

Advantages of State Transition Testing

• By utilizing a visual or tabular representation of the system’s behavior, this technique familiarizes testers with the application’s design, making it easier to effectively and efficiently cover and design tests.
• This technique also covers unplanned or invalid states of the system.
• It is easy to verify if all the conditions are covered using the State Transition diagram.

Disadvantages of State Transition Testing

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

Conclusion

State Transition testing is a valuable approach for testing transitions in finite-state systems.

Testing an application using the concept of “Stateful Functional Testing” provides Testing Organizations with a unique test approach for testing complex applications. This approach increases test execution productivity without compromising on test coverage.

State Transition testing is a unique test approach for testing complex applications. However, it can only be used in systems with finite states.