Bug bounties

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!)

Advertisements

4 thoughts on “Bug bounties

  1. 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?

  2. 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?

  3. 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!)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s