As Cem Kaner said:
The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.
Which refers to a tester doing his or her best to make a developer fix a bug he or she detected.
What are the general guidelines to properly sell a bug and make a developer interested/motivated in resolving the problem?
Well, the book Cem co-authored with James Bach and Bret Pettichord has a whole chapter on "Bug Advocacy". Some excerpts:
State the benefit so that your prospect will want it. Your bug report should make it clear to the reader why he should want to fix this bug. For example, you might explain how the bug interferes with normal use of the product, what data it corrupts, or how often people will run into it. You might point to a magazine review or other published complaint that savaged a competitor for a bug similar to this one. You might quote technical support statistics to show that bugs like this one in other products have cost a lot of money. You might show that the program passed this test in a previous release. (This is a key issue in some companies.).... In many cases...you can take a relatively minor-looking bug and discover more severe consequences by doing follow-up testing, rather than reporting the first version of the bug that you see.
Anticipate objections to the sale and counter them. ...[follow] good reporting practices: Write clearly and simply and check (and report) that the bug replicates on multiple configurations....
- From Lesson 57, "Make your bug report an effective sales tool"
And:
Efficient testing often involves extreme values. The first errors you find will often be at the extremes.... Some programmers cry "corner case" when they see a test result that involves an extreme value or a combination of extreme values.... Don't stop with [the extreme value] result. Instead, try smaller numbers until you learn what range of supposed-to-be-acceptable values are rejected. If the program rejects anything bigger than 99, you can report that it fails throughout the entire range of 100 to 999. This will capture attention. If the program fails only at 999, that is useful information, too. Report it explicitly.
- From Lesson 71: "Uncorner your corner cases"
Some other lessons whose titles speak for themselves:
Lesson 59: "Take the time to make your bug reports valuable"
Lesson 64: "Draw the affected stakeholder's attention to controversial bugs"
Lesson 67: "Report defects promptly"
Lesson 73: "Keep clear the difference between severity and priority"
Lesson 78: "Be conscious of the processing cost of your bug report"
Lesson 84: "Never exaggerate your bugs"
Lesson 85: "Report the problem clearly, but don't try to solve it" [devs may reject a bug if your proposed solution isn't actually correct]
Lesson 86: "Be careful of your tone. Every person you criticize will see the report
Lesson 87: "Make your reports readable, even to people who are exhausted and cranky"
Lesson 88: "Improve your reporting skills" [gives example of "Compare closed bugs that were fixed and not fixed. Look for differences in the way they were reported."]
I could go on. There's a good bit to learn just by reading the table of contents of this book :)
From my own experience as a developer who also writes and runs tests, my main hurdle is getting bugs past our change review board, not other developers. For that situation, it seems that getting enough detail about root cause, size of fix, and possible risk are the main points that help get a bug fixed, especially late in a project. It's also hard to defer a bug that's "fixed on a branch" though that's not necessarily applicable to reporting bugs to developers. I've also found that including details like "I found this by following the instructions in the tutorials we give to customers" carry a lot of weight.
