Last year David Williamson invited me to review this article on the “perfect” bug report before it was posted: http://blogs.msdn.com/ejarvi/archive/2005/08/01/446126.aspx
With all the advice about what to put into bug reports, it got me thinking about things I’ve learned not put into bug reports. :)
It seems like there are some bug reports that only make your life harder in the long run. A few years into my testing career here I took a look back at all the past bug entries I had ever logged. I was trying to make my ratio of bugs fixed to bugs logged really shine. Many of the duds that jumped out from this query were because I tried to influence the bug report towards how things “should” be. In fact I was using the word “should” a lot. This attitude seemed to unlock a pandoras box of reasons and excuses for the developer not to fix the bug.
One thing that seemed to work for me was just red flagging the word “should” and taking it out of my bug reports. That forced me to consciously separate the description of the defect from the decision about waht to do about it. Lock the perpetrating defect in the bug database, and when its day in court arrives you can have a much stronger case against it having spent your time on preparing an intelligent case and getting your facts straight. And it makes the game a lot more fun.