State Transition Testing:
State Transition Testing is a technique that is used to test the different states of the system under test.
The state of the system changes
depending upon the conditions or events. The events trigger states which become
scenarios and a tester needs to test them.
A systematic state
transition diagram gives a clear view of the state changes but it is effective
for simpler applications.
More complex projects may lead to more complex
transition diagrams thus making it less effective.
If you request to withdraw £100 from a bank ATM, you may be given cash. Later you may make exactly the same request but be refused the money (because your balance is insufficient).
This later refusal
is because the state of your bank account had changed from having sufficient
funds to cover the withdrawal to having insufficient funds.
Another example is a word processor. If a document is open, you are
able to Close it. If no document is open, then “Close” is not available. After
you choose “Close” once, you cannot choose it again for the same document
unless you open that document. A document thus has two states: open and closed.
A state transition model has four basic parts:
•
The states that the software may occupy
(open/closed or funded/insufficient funds);
•
The transitions from one state to another (not
all transitions are allowed);
•
The events that cause a transition (withdrawing
money, closing a file);
•
The actions that result from a transition (an
error message, or being given your cash).
Note that a
transition does not need to change to a different state; it could stay in the
same state. In fact, trying to input an invalid input would be likely to
produce an error message as the action, but the transition would be back to the
same state the system was in before.
Deriving test
cases from the state transition model is a black box approach. Measuring how
much you have tested (covered) is getting close to a white box perspective.
However, state transition testing is generally regarded as a black box
technique.
You can design
tests to test every transition shown in the model. If every (valid) transition
is tested, this is known as “0-switch” coverage.
You could also
test a series of transitions through more than one state. If you covered all of
the pairs of two valid transitions, you would have “1-switch” coverage,
covering the sets of 3 transitions would give “2-switch” coverage, etc.
However, deriving
tests only from the model may omit the negative tests, where we could try to
generate invalid transitions. In order to see the total number of combinations
of states and transitions, both valid and invalid, a state table can be used.
Let’s take
some scenario to develop test cases,
•
The first test case should be very much sensible
to enter the correct PIN at the first time
•
The second test should be to enter an incorrect
PIN each time, so that the system rejects the card
•
To test all transition, firstly do the testing
where the PIN was incorrect the first time but OK the second time and another
test where the PIN was correct on the third try
•
But, these tests are basically less important
than the first two tests
Table below shows
the state table lists all the states down at one side of the table and all the
events that origin transitions along the top (or vice versa). Every cell then
symbolizes a state-event pair.
The information of
each cell shows which state the system will shift to, when the resultant event
arises while in the associated state.
This will contain possible erroneous events – events that are not
accepted to happen in certain states. These are negative test conditions.
This Table shows different states in the first column and the respective
inputs across the top row. For Example:
Suppose the system is in state 1, after inserting the card it will go
to state 2.
If system is in state 2, after entering a valid PIN, it goes to State 6
to access the account. In State 2 if we enter an invalid PIN it goes to State
3.
In the table, a
dash (-) sign represents invalid transitions of that state. A question mark in
two cells – either a valid or invalid PIN, when we are using the account.
0 Comments