|
shared by Ravi Sankar
The race against time is the underlying truth in
all delivery cycles. As demands from the clients get steeper - seeking greater speeds, volumes and convenience,
the accuracy is a factor that cannot be compromised on. Thus, we seek an effective methodology that would not only
enable a
speedy delivery but also keep the sanctity of code intact.
The Pareto principle applied to Software Quality Assurance says:
"20% of the modules contribute 80% of the errors"
The basis of the Pareto Principle is an effective classification of bugs, based on their attributes. The bugs are
classified according to the Priority that they should be addressed and fixed.
Priority1- Bugs that are show stoppers and cause failure of business critical functionality.
Priority2 - Bugs having no workaround but are not Priority1 bugs.
Priority3 - GUI related bugs, bugs which are not based of the core functionality of the Software
and bugs which have a workaround.
Using the Pareto Principle, the aim is to find the maximum number of Priority 1 bugs and Priority
2 bugs in minimum cycle times. On many occasions, the testing professionals do not have enough time to execute
all the test cases.
As the release date of the software approaches and the timelines give absolutely no leeway to fix Priority 3 bugs,
the workaround of the Priority 3 bugs are specified in the release notes. Thus, the focus is on uncovering as many
Priority 1 and Priority 2 bugs as possible in the Software before its final release.
Thus, the trick of applying the Pareto Principle is to identify the error prone modules in the 1st cycle and concentrate
on them in the 2nd cycle to uncover more and more bugs. The detailed procedure is as follows:
The first step is to ensure that the cross-functional teams or Offshore/Onsite teams review the test cases written
by the testers and incorporate the review comments in the test cases. On getting a build to test, it is important
to ensure that the Software meets the 'Entrance Criteria' for testing, i.e. Software meets the minimum (say 75%)
requirements.
Failure of the Software to meet this 'Entrance Criteria' implies rejection of the build and requires an enhanced
build from the development team.
Once the Software passes the 'Entrance Criteria', it is tested for the maximum number of bugs as possible in the
first build. Upon completion of the first build, the bugs are categorized according to their priority and their
module. A bar chart as shown under is constructed on that basis. The bugs of the module point to the bugs related
to the module's functionality and the bugs related to the module's integration with other modules.
On receiving the 2nd build after the successful completion of the 'Entrance Criteria' for testing, the concentration
shifts to testing the modules, which have the maximum number of the sum of Priority 1 and Priority 2 bugs.
Upon successful completion of the testing of the
2nd build, a similar bar chart is constructed, depicting all the modules. The same steps are followed and the 'Entrance
Criteria' on the 3rd build are determined.
In general, on receiving the 1st build, the build is tested for 'Entrance Criteria'. On passing the 'Entrance Criteria',
the build is tested completely. Before starting the testing of the (n)th build (here n=2,3,4…. etc); the same bar
chart is constructed depicting all the modules for the (n-1)th build. Then, the 'Entrance Criteria' on the (n)th
build is performed. Then, the corner cases of the modules which have the maximum of the sum of the Priority 1 and
Priority 2 bugs in the (n-1)th build are focused on. For this, from Figure (n-1), some resources are allocated
from the less error prone modules to high error prone modules. The underlying hypothesis that there are cycles
of less duration to perform the complete testing is the success factor of this technique.
The above implementation could have also been done by considering the sum of the Priority 1, Priority 2 and Priority
3 bugs instead of just the first two. But it was done with the two higher priorities as there could have been a
shift of focus from the highly error prone module, to the ones that could be fixed at a later time.
 Share your thoughts on Maximum Bug Fixing in Minimum Time in SQAtester Group.
 E-mail to a Friend.
About the Author:
Ravi Sankar, is currently working with Satyam Computers as a Quality Analyst. Previously he worked with Sun Microsystems
and HCL Perot Systems. Ravi has six and half years of experience in Software development and Testing. He obtained
his M.Tech in Computer Applications from I.I.T. Delhi. His interests include getting acquainted with the latest
trends in the IT field and in Software Testing.
Ravi can be reached at: ravi_sqa@yahoo.com
|
