Simplify your bug report

Communication between developers and testers plays quite important rule, often we see a debate going on about the bugs between developer and tester, there are few Things that makes programmers to resist spending their time on the bug that are:

• 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 bug report.

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. Programmers operate under time constraints and competing priorities. 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.

How to simplify your bug report
1-Write each step in detail.
2-If you see two failures, write two reports combining failures on one report creates problems: 3-You’ll often see one bug get fixed but not the other.
The summary description should not be vagued. The words like “fails” or “doesn’t work” should not be used instead of describing the failure more vividly. This weakens the Impact of the summary.
4-Put Variations after the Main Report Suppose that the failure looks different under slightly different circumstances. For example, the timing changes if you do a additional two sub-tasks before hitting the final reproduction step. This is all useful information for the programmer and you should include it. But to make the report clear.
5-Write suggested solution if possible.
6-Write expected Benefits to the customers and vendors

you can read the detailed article on bug advocacy from here