Brent Strange reports that some major companies – notably Microsoft, Mozilla and VeriSign – have begun rewarding their testers with cash for finding serious defects prior to release. It seems to me that this approach is seriously flawed, in at least two respects.
First, it further promotes the traditional antagonism between developers and testers. There’s now a clear reward for testers to find the developers’ work wanting. How does that help to build trust or teamwork?
And second, it rewards the testers for not helping the developers get it right sooner. Sure, the cash will be less than the cost of releasing with a serious defect, but it will also be less than the cost of rework due to finding the defect late in the value stream.
The solution? Both developers and testers should be rewarded when the pre-release testing finds no defects.* Instead of rewarding antagonism, reward collaboration. And reward the reduction in rework. Have the testers engaged at the front of the value stream, creating automated self-checking tests that will help the developers get it right – and complete – first time.
* (Footnote: this needs to be balanced by penalties of some kind if the pre-release tests are skimped in any way!)
Josh
May 19, 2006
Interesting post, but I’m a bit scared by the culture your solution might create :)
http://www.thejoyofcode.com/Bug_bounties.aspx
Kevin Rutherford
May 19, 2006
Hmmm. Josh, you’re right of course. I would love to find a way to reward both developers and testers when they collaborate early, so that defect insertion is prevented. Can you think of a way to do that?
Josh
May 19, 2006
Actually, I’d worry that the whole concept could be flawed and open to abuse. If we look at the simplest example where testers are rewarded for finding bugs – developers could plant bugs for testers and split the winnings.
I’d probably drop the whole idea. We don’t pay developers commission on lines of code produced – and it would be a terrible idea! Nor should we pay testers commission on bugs found.
It’s quality we’re after and that’s very hard to measure. Maybe a bonus for both teams six months after release based on the number of issues? But would this reduce have a negative effect on the development process in other ways; such as embracing change?
Kevin Rutherford
May 19, 2006
Agreed. Perhaps the only sure way to get what I’m after is to focus on driving down cycle time (the time between a feature’s request and it’s release), and point out that support and rework both keep that metric high…
(Anyway, we’re both agreed that cash for bugs is less than ideal!)