Monday, January 19, 2009
IMPROVE TEST EFFICIENCY - Weighted graph methodology
Existing process of test execution
The normal process followed for execution of test cases manual or automation is to follow the sequential order of test case as presented in the overall test plan for the concerned module. The common order of cataloging test cases in the test plan for a particular module would be to group them by functionality or by the common factors of the various test scenarios involved. This is to ensure that the designer of the test case does not miss any valid test scenario. The purpose of the approach which is presented in the following sections addresses the following problem area which is typically encountered.
“Tester xyz is handling the testing of a particular module which encompasses 5 broad functionalities. The test plan he uses has test cases grouped into these 5 categories and presented sequentially in his test plan document. He is scheduled to complete testing of the module in 10 days. He starts off execution of test cases sequentially and ends up repeatedly executing test cases relevant to the first functionality to completion and so on.
Assumption: Of the 5 functionalities assume the first 3 are extremely bug free while the 4th and 5th are extremely buggy. Since tester xyz will spend the major part of the early period testing the first 3 modules sequentially he would take longer to zero in on the bugs hence delaying the reporting of bugs leading to delayed cycle times where the development team would be waiting on him during the early period.”
The weighted graph methodology
The weighted graph methodology modifies the process of test case execution as follows. The module to be tested is first represented in the format of a weighted graph for example:
Structure of the weighted graph:
Where the leaf node represent the different functionalities bundled in the module. The squares in blue represent the weights of each limb of the graph in the beginning (here 0). The cylinders show the subset of test cases that can be tagged to each of these functionalities.
Executing test cases the “weighted graph way
To begin execution of test cases using weighted graphs; QA first develops a script which performs the following:
1. Pick a test case using a probabilistic approach depending on the weight of the limb from any one of the subset of test cases for all the functionalities.
2. The tester then executes that test case either manually of via automation scripts.
3. The result of the test case namely “pass” of “fail” is communicated to this master script.
4. If the test case fails then the script increases the weight of the limb for that functionality by a factor say 1.
5. In the next iteration of the above steps the probability of a test case from the limb with more weight being picked is higher.
6. The above steps repeat till all test cases have been covered.
Benefits of using weighted graph method
The weighted graph approach is beneficial because the tester ends up executing more test cases that are tagged to a possibly buggy module hence the ratio of the number of defects identified to the number of test cases executed increases. Hence the defects in a module are identified at the early stages of testing. This translates to reduced cycle times and more throughput for the testing activity.