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.
‘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.
1.1 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.
Point to note 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.
Point to note 3: This is not only useful for testing the individual components, but also for testing the system end to end.
Point to note 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.
Point to note 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 were 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.
Point to note 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.
Author: This article is contributed by Ramesh Ramamurthy who is working in a top MNC in software testing field.
Further reading: State Transition Testing Technique for designing test cases.