You're sitting in front of your computer doing one of your daily tasks in, let's say NAV. But @*^%$#@$$!!!!, the darn system does not do what you expect it to. Just one of these days? Might be, but it seems to you the system is not just doing something different than you expected, it clearly errs. A fix is needed to enable you to finish your task. Pffff ... no time; a busy day, but no other way than to contact the help desk at your Dynamics NAV partner and tell them a fix is need right away! Unfortunately as always you're asked to register the bug by means of a comprehensive bug report.
"What the .... (beep), I am sitting here in front of NAV in it says .... It's clear it's a bug and we need a fix ... now!"
Don't we all find ourselves in a similar kind of situation once in a while? We're under pressure because of what we are doing and are blocked on the way doing it. And then we are urged to provide a bug report. As no other way seems possible to get a fix, you do what is asked and create the report (by whatever means, in whatever system your partner is using). But the water is still boiling as you think: "@*^%$#@$$!!!! "; "Not your fault the system errs"; "Now I am punished for something I have no part in"; ... Not the best mood for writing a comprehensive bug report. You might ask yourself:
Is this the way I am going to get it fixed asap?
Most probably we agree and will answer this question with: no.
If you really want to get your issue solved: sell it! Not by just saying it's an issue and it is a high severity one, but indeed by providing:
Do your utmost best to get the developer in the good position to fix your bug. That he loves to solve your issue(s).
... to Tracey Montieth at MS for having learned me to change my attitude toward bug reporting.
Today I read this nice blog by Bj Rollison: www.testingmentor.com/.../better-bug-reports.
Another view on the same.