During a Support Team/Test Team collaboration, I was coaching a technical support team member through logging a bug. I suggested my usual template.
Repro Steps:
1. Do this.
2. Do that.
Expected Results: Something happens.
Actual Results: Something does not happen.
Afterwards, I said “That’s it.” She looked over the Spartan bug report and was reluctant to let it go. she said, “It looks too bare bones.” She wondered if we should add screen captures and more commentary. IMO, when a bug has repro steps, that’s all you need. And the fewer the better! Sure, a picture is worth a thousand words. But sometimes it only takes about 14.
If you’ve ever participated in bug triage meetings, you’ll probably agree. People love to fill bug reports with non-essential comments that obscure the spirit of the bug and discourage anyone from reading it.
“After those steps I tried it again and got the same error.”
“Maybe it is failing because I am doing this instead of that.”
“I remember it used to not throw an error, but now it does.”
“We could fix it by doing this instead of that.”
It’s a bug report, stupid. Report the bug and get back to testing. Opinions and essays are for blogs.
…Praise for the simple, bare bone bugs.
RSS
All I have to say is "Amen"!
yup totally agree just put the essential in the bug report. I normally try to include screenshot and workaround (although this is not mandatory) as part of the report.
1. What about situation in which you are not 100% certain that what you see is the bug ?
2. What if your requirement is not formal written, and you report the bug based on oracle heuristics ?
3. What if something which seems as a bug for you is feature for someone else ?
Would you still use "bare bone bug reports" ?
I agree. Besides, I hate when I write a very complete report, with details, screen shots, logs, etc and then the dev does not even open the attachmments and pings me instead.