It has been long established that gauging a Testers work based on the amount of bugs they discover/report is about as useless as gauging a Developers work based on the amount of lines of code they write. One tester might discover 20 non-critical bugs and another might discover 1 huge application breaking / soul destroying beast of a bug. In the long run these are both valid contributions when we are talking about the overall process of Quality Assurance; being in one group or the other certainly doesn’t
reflect on your ability as a tester and you shouldn’t read to far into
these numbers.
However just because the metric is useless at gauging productivity it doesn’t mean that we can’t use the information in some other way, I have listed a few ideas below:
(i) Reporting multiple bugs in the same area of the application might indicate that there are even more in that particular area. If we slightly modify the idea put forward in Pareto’s Principal which states “80% of the effects come from 20% of the causes” then you can suggest it is likely 80% of the bugs in an application come from 20% of the code (of course this principal should not be taken completely literally).
(ii) If while testing you are discovering lots of silly little bugs it could suggest that your development team are under pressure and as a result their work is being rushed and beginning to suffer. While this would no doubt be fairly obvious to the team it could provide more quantifiable data for management to analyse.
(iii) While the metric itself might be useless I do get a rather strong sense of satisfaction from running a query on TFS to select and view all the bug work items that I have reported. Its little reminders like this that can help in keeping a workforce motivated.
Testers will always find bugs – small or big. But I’m fairly certain that there are probably companies out there the demand that their test teams fulfil a Quota of reported bugs. In many ways this could even have a negative impact on the test teams work; they may be forced to concentrate on non-critical areas of the application just so they can meet the quota that has been placed upon them. Testers should be free of such pressures so they can focus on ensuring their test plans have the greatest coverage possible for the timeframe they have available to them.
P.S. Just as I was finishing writing this the following link popped up on my tweetdeck, the timing was so freaky that I decided to include a link:
http://www.thetestingplanet.com/2011/07/how-to-successfully-measure-the-testers-performance/