With crowd testing, price per defect model is getting more popular. In this model crowd tester or the crowd test organization is paid per valid defect found. One of the challenge we see in this model, testers concentrate only in areas where it’s easy or quick to find defects and it leads to test coverage issue.
How can we encourage to focus on business critical modules or functionalities where it’s difficult to find defects? The difficulty in finding defects is due to either stable code or better design and coding team.
One of the way to encourage is to tie defect density to price per defect. There are several interesting interpretation of defect density exists, the following is the ISTQB definition
Defect Density is the number of confirmed defects detected in software or component during a defined period of development or operation divided by the size of the software or component.
i.e Defect Density = No. of defects / Size, The size of software or component is defined using lines of code or function point.
How do defect density used with Price per defect?
Most of the price per defect model has price based on the severity of the accepted defects, typical severities are Minor, Major and Critical. You can further add weightage based on the defect density. If defect density is higher, you are finding more defects in a particular module, lesser defects if density is lower.
For e.g. if 25% weightage is added for defect density < 10%, defects are paid 25% more than normal cost, also, we can bring down price per defect where density is higher.
We can also add weightage such as business criticality along with defect density and severity.
Looks only more money can be only motivation in this model to increase coverage
This article was written by Suresh Ramakrishnan from CapGemini: Capping IT Off and was legally licensed through the NewsCred publisher network.