The title pretty much says it all (I hope), but let’s take a look at some key excerpts from this 100-page masterpiece to find out more. First the, the premise:
- The point of testing is to find bugs.
- Bug reports are your primary work product. This is what people outside of the testing group will most notice and most remember of your work.
- The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.
- Programmers operate under time constraints and competing priorities. For example, outside of the 8-hour workday, some programmers prefer sleeping and watching Star Wars to fixing bugs.
A bug report is a tool that you use to sell the programmer on the idea of spending her time and energy to fix a bug.
Motivating the Bug Fixer
Some things that will often make programmers want to fix the bug:
- It looks really bad.
- It will affect lots of people.
- Getting to it is trivially easy.
- It has embarrassed the company, or a bug like it embarrassed a competitor.
- One of its cousins embarrassed the company or a competitor.
- Management (that is, someone with influence) has said that they really want it fixed.
- You’ve said that you want the bug fixed, and the programmer likes you, trusts your judgment, is susceptible to flattery from you, owes you a favor or accepted bribes from you.
Overcoming Objections Via Analysis of the Failure
Things that will make programmers resist spending time on the bug:
- The programmer can’t replicate the defect.
- Strange and complex set of steps required to induce the failure.
- Not enough information to know what steps are required, and it will take a lot of work to figure them out.
- The programmer doesn’t understand the report.
- Unrealistic (e.g. “corner case”)
