State Transition testing is a kind of Black-box testing that may be used to test 'Finite State Machines.'
A 'Finite State Machine (FSM)' is a system that, depending on the inputs or stimuli, will be in several discrete states (such as "ready," "not ready," "open," "closed," etc.).
The discrete states that the system achieves are determined by the system's transition rules. A finite-state system is one that produces distinct outputs for the same input depending on its previous state.
It's also known as "0-switch" coverage when every transaction is tested in the system. It's "1-switch" coverage if the testing covers two pairs of legitimate transactions, and so on.
When a system is specified in terms of a limited number of states and the transitions between them are guided by the system's rules, the state transition approach is applied.
In other words, when aspects of a system are represented as states that transition into one another, this method is applied. The rules of the program dictate the transformations.
To give you an example, consider the following −
"You go to an ATM and get $1000. You'll receive your money. Now you're out of money and make the identical withdrawal request of $ 1000. This time, the ATM refuses to give you money due to a lack of funds. As a result, the earlier withdrawal is the transition that triggered the change in status."
We can now arrive at a more relevant definition for State Transition testing after understanding what State Transition is. As a result, it's a kind of black-box testing in which the tester must evaluate the behavior of the AUT (Application Under Test) in response to a series of input circumstances.
For both positive and negative test results, the system's behavior is recorded.
The following scenarios can benefit from state transition testing −
When the under test application is a real-time system with several states and transitions.
When the application is reliant on prior events, values, or circumstances.
When it's time to put the sequence of events to the test.
When the program must be evaluated against a set of input values that are limited.
State Transition testing should not be used in the following scenarios −
When consecutive input combinations do not need testing.
When the application's many capabilities need to be tested (more like Exploratory testing).
Implementation Steps −
Identifying distinct components/parts of the application that may be classified as FSMs is the first step in performing 'Stateful Functional Testing.' Each of these FSMs' inputs, states, and outputs are meticulously recorded.
The next step is to create test cases based on transition rules, inputs, outputs, and transition states for these FSMs.
The last stage would be to combine the testing of these components with the testing of other interface components in order to validate the application from start to finish.
This can be illustrated using the example of an application called "House Project," which tracks the construction of a house and includes components such as approval of the house's architecture, registration of the plot and house, selection of the building contractor, approval of a housing loan, and so on.
Example − Approval of the Housing Loan is one FSM component of the "House Project" application that we will evaluate.
A separate Loan Processing User will run the HLA application and process the loan application. The following are the steps involved in the application's processing −
The first step is to gather the necessary documentation to apply for the loan, as shown in the table below. They are the requirements for submitting a successful application. The applicant gathers the relevant papers and submits them with the application for a house loan.
The Loan Processing User confirms receipt of the papers and changes the Loan Application's state (that is, the HLA Application component's state) to "Applied."
The lender evaluates the Loan Application at this point to see whether it fits his credit standards. At this point, the supporting papers are checked.
The assessment papers, i.e. the "conditions" that must be certified at this step, have been validated. Each condition has a criticality associated with it (shown in the table above as 'Y'). The application advances to the state "Confirmed" – that is, the HLA application component is in the "Confirmed" state – after all of the requisite critical criteria are met.
Take notice of the following −
This concept gives the system's test conditions and "State" definitions structure and objectivity. Furthermore, not all of the "criteria" for validating the system are required for it to achieve this "Confirmed" state. For the application to achieve the "Confirmed" level, four requirements are highlighted as "Not Critical" in the table above.
Depending on the risk or criticality of the rules necessary for each state, the number of validations may be ideally decreased. This will dramatically minimize the amount of time it takes to run a test while maintaining the same level of testing quality.
Not only is this valuable for testing individual components but it can also be used to test the whole system.
Can also be used to create regression test suites. So, it's a 0-switch kind of testing at this point. Later phases of approval, on the other hand, might have 1-switch or 2-switch validations. For example, "Marriage Certificate" may not be particularly relevant at this stage, but later in the approval process, when the applicant's ability to pay the EMI is taken into account, the marriage certificate may become relevant – that is, if the spouse is also employed, the risk is reduced, and if not, the risk is increased.
Depending on the component's requirements at the time, the aforementioned technique may be applied to increase the test circumstances.
The application's current status is "Confirmed." For the loan procedure to proceed further, the lender would provide "Conditional Approval." Moving the HLA application to the "Approved" level will need further validations.
At this point, critical validations are carried out −
Lenders Mortgage Insurance (LMI) assessment: This would need two or more validations for the property's authenticity. The Lender has the right to request information that was not provided at the "Confirmation" step.
The application is moved to the "Approved" status after the preceding prerequisites are met. The ultimate authority in charge of the approval procedure may ask for further information from the Loan application or may not inquire whether the Applicant's other papers are conclusive. To establish the correctness, further inputs from other components of the primary application would be necessary.
In other words, depending on the input circumstances to the component from other components of the application, additional validations may be needed (or decreased) for the transition to a new state.
Deep application knowledge is required for big applications in order to break them down into logical components that may be classified as FSMs or ordinary components. This may need a significant amount of time from SMEs.
This kind of FSM classification would not be feasible for many applications.
Because FSM components interact with other application components, inputs to FSMs from other components must be carefully planned and executed.
The tester gets acquainted with the application design and finds it easier to cover and create the tests effectively and quickly using this method, which involves employing a visual or tabular depiction of system behavior.
Using this method, the system's unplanned or invalid states are likewise covered.
It's simple to check whether all of the requirements are met using the State Transition diagram.
Nonfinite state systems cannot be solved using this method.
It's a difficult undertaking to define all conceivable states for big and complicated systems.
When alternative system transitions must be examined for finite-state systems, state transition testing is a useful technique.
Testing complicated systems using the notion of "Stateful Functional Testing" might provide Testing Organizations with a unique Test Approach for increasing test execution efficiency without sacrificing test coverage.
State Transition testing is a novel way to test complicated systems that increases test execution efficiency while maintaining test coverage.
The technique's restriction is that it can't be employed until and until the system under test has only limited states.