Myself & jOHn (a.k.a “the pikey” cos he’s watched snatch one too many times n takes the software down in the first punch 
)were sitting down to our usual boxing match on software testing. They say tha’ testing is never complete. Well this is what we made of it tha’ day…..
Let’s start at the very beginning, a very good place to start. I have this code snippet that I have boxed into a wonder software. This is wha’ it does “Find the sum of 2 numbers”. Now if the world of software testers out there say that we could all sit and test it for a decent amount of time but still not ship it bug free, its time we hung up our boots
So this is the anthem, “Theoretically the number of bugs in an application/software is a finite number. The process of testing uncovers these bugs and their numbers go down. Hence mathematically there is a point in time (which does not tend to infinity) where there are actually 0 bugs in the software under test.”
The loudest outcry against this is that “time is your biggest enemy”. Most software development projects do not/cannot afford the time factor to reach that stage of zero defects. Most commercial testing is hence forced to stop at the light blue zone. The pink zone is classified as “phantom defects” and left to be.
Hence the job of software testing needs to re-classified from that finds bugs to one that also finds the time to find bugs. Let a so called “phantom bug” be just because we didnt get the time to do it is inexcusable (Sounds kinda like a developer saying that he didnt implement only 90% of the functionality cos that all the time he had).
This is where we require approaches and philosophies to improve test efficiency. Software testing needs to be a defect-time function. Below is a proposed methodology to increase your testing efficiency called the Weighted Graph Methodology.
Stream Lining Test Execution
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.
As for pikey…..well he now wants to take the software down with every punch
If you enjoyed this post, make sure you subscribe to my RSS feed!
