Deriving Black-Box Test Cases from a State Transition Diagram (STD)

Transition Tree

Demonstration: Deriving the Transition Tree from the STD

From the state model, we can proceed with the test case design by developing a transition tree. The initial state is the root node of the tree. So, the root node for Account class is the initial state of Account - open. For each transition from the root state, draw a branch to a node that represents the next state. Repeat this for each state unless the next state is the final state or the next state appears in the ancestor node.

The next phase of test design is to get the test sequences from the transition tree. Each branch of the tree becomes a test case (Chow's algorithm). Covering this tree will discover bugs that may be missed by just testing each method, transition, or state once.

 

The Test Sequence

Demonstration: Deriving the Test Sequence from the Transition Tree

The test sequence is created by traversing the state transition graph. The test sequence should start from the initial state, go through all the possible transitions, and return back to the initial state, in a depth-first fashion.

The test sequence derived from the transition tree of Account class are:

1. open-balance (after creation of account object, invoking operation, open, and querying the attribute, balance)
   
2. open-deposit (exercising test sequences 1 & 2 a number of times will not alter the object’s state)
   
3. open-withdraw ( exercising it one or more times)
   
4. open-withdraw-balance (querying attribute, balance after withdraw operation, object’s state – overdrawn)
   
5. open-withdraw-deposit (after deposit operation, object’s state may still be overdrawn)
   
6. open-withdraw-withdraw (withdraw operation in an overdrawn state should not proceed)
   
7. open-withdraw-deposit (deposit operation with enough amount changes object’s state from overdrawn to open)
   
8. open-freeze-balance (freeze operation to change object’s state to frozen & query balance of a frozen account)
   
9. open-freeze-unfreeze (operations change object’s state from open to frozen & back to open)
   
10. open-deactivate-balance (deactivate operation changes object’s state to inactive; query balance)
    
11. open-deactivate-settle (settle operation causes the object’s state to transition from inactive state to closed state)
    
12. open-close (operation open followed by close - object’s state from open to closed)
    

The operations listed in the test sequences above respond to a particular state of the account object by either:

• remaining in the same state after an operation, or
  
• changing from the current state to a new state, or
  
• leaving the object’s state in an error state.
  

The parameters or arguments of the operations (if applicable) are relevant in this context. They are not shown in the test sequence but are part of the test cases. The test plan is produced by identifying the method arguments & their values, and the expected state and possible exceptions for each transition. The actual test run involves setting the object under test (OUT) to the initial state, applying the test sequence, and checking the final state.