Allen, one of the developers on my team, recently told me about some poorly written bugs he had received from a tester. Allen said,
"Basically these bugs describe the application behavior as a result of user actions working with an application, without any explicit identification of the buggy behavior. This tester wrote many, many bugs with one or two sentences. His bug description pattern was like this:
When I do A, it does B.
Examples:
- When I try to move the video object, the background image stays still. (OK. Where is the bug?)
- When I set the video file to a path located in another course, the file is copied to the current course when rendering the page in IE browser. (To some, this may be the correct behavior. So where is the bug?)
This is an ambiguous way to describe a bug. It frustrates me! "
About a year ago, Allen offered similar candor on several of my bugs. Since then, I have made it a point to force the following two statements into every bug I log.
Expected Results:
Actual Results:
No, it’s not an original idea. But it is an excellent idea that makes it nearly impossible for one to ever log another ambiguous bug. If the tester had used it for one of Allen’s examples above, we might see the following.
Expected Results: The background image moves with the video object.
Actual Results: The background image does not move with the video object. Instead, the background image stays still.
Expected Results/Actual Results. Don't log a bug without these!
RSS
Well, Eric, that's very interesting. I am a software developer. At my work, I have come across a similar situation with testers not describing clearly about "buggy behavior." In fact, this style of description is quite often and natural to some people who often assume what others know s/he is talking about. Here is a recent example .
"All promos/events on both alternates do not appear in the recon file. My franchises appear in the recon file as No Run. My promo and event on both alternates do not appear in the recon file."
When I first read this bug description, I couldn't figure out where the bug is.
Hmmm...
That's a bad one. What is the bug? Do all three sentences describe a bug or something that works as designed? What are the repro steps? ...Terrible.
I hope I am correct in assuming this bug report did not come from a software tester.
Eric,
I work at an insurance company, and in every reasonable situation that I can think of, the testers here have used the exact format that you are prescribing. I think it works well, but I've also noticed an additional problem: Why does the tester's expected results matter?
This is part of selling our bugs reports, and the HICCUPPS mnemonic, http://www.developsense.com/articles/Testing%20Without%20A%20Map.pdf, helps me in focusing my research and providing a strong argument for why I expect the application to behave differently.
I suspect you've seen this before, but if not then I hope it helps you and the readers as much as it has helped me.