The Importance of writing good bug reports
I was copying over some old bug reports into our new database the other day, It would have been nice to just import them all in, but if that was the case I would have missed out on the first hand realization of good bug reporting. As I was copying them over I noticed the difference in the bugs that were written before we were put on the project. Now I am not slinging mud at anyone nor tooting my own horn. But the difference was painfully obvious. The bugs that were poorly written had tons of notes added to them like, “Cannot repro” What do you mean by this abbreviation” “Please explain” and on and on. I also noticed the poorly written bugs took almost twice as long to come to a decision about and close.
If you have been writing bug reports for years and years, you’re probably thinking, I don’t need to read any further, I KNOW how to write a GREAT bug report! If that’s true I have a challenge for you!
Knowing how to do it and DOING it correctly are two separate issues. I have found in the Software industry , the longer test engineers write bug reports, the more the information in the reports tends to get muddled in speak that only makes sense to those directly on the project. Or shortened down to a brief description that leaves out the “Obvious” steps. I have even seen bug reports that are simply the Description line.
And how is this helpful to the Developer in another state or Country? She may not know what your acronym means, she may need the “obvious” steps you left out in order to correctly repro the bug, and using the description line as your bug report is, well, that’s just sad. (You need to shape up or ship out mister!)
It takes allot of time for information to get interpreted and dealt in a cost effective manner, add in language barriers, distance and the ongoing trend of outsourcing and a poorly written bug report can suddenly add up to allot of unnecessary time, money and effort!
How can I tell if my bug reports are written properly? Well, in my opinion, the correct answer is, Do your bug reports reflect the teachings of the Great Master Jedi Kaner in his manuscript testing computer software? If you’re still not sure then here’s a sure fire answer, Can your Mom or Dad repro your bug report? I guess you could say your dad invented the computer or something and totally can, but what I mean is, can someone NOT on the project with limited technical skills pick up your bug report and repro it. If the answer is no, Then it’s time to dust off that Kaner book. If the answer is yes, then congratulations! Now show someone else what you are doing, maybe your good habits will rub off on them!
Subscribe to:
Post Comments (Atom)
Can you give any specific examples of a poorly written bug report or of a good one?
ReplyDeleteHow do I manage the time I spend crafting great bug reports vs. the time I need to spend testing to find more bugs?
Good reminded, especially for crusty-old-guys like me. After a few years of success as a test engineer it becomes easy to "talk-the-talk". But, complacency sets in and perhaps a touch of arragance, and pretty soon there's a big gap between how good I think my bug reports are vs. how good they really are.
ReplyDeleteMy #1 check-point is the Dev I'm working with. My habit is to write my first couple bugs and then go sit-down with the Dev and review the reports together. I ask: "Is this what you need"? "Is this enough detail or too much"? Is this too many steps or too few?" "Will this style work for you?" Of course, this is much harder when you've got distributed teams, unknown Dev's, or the frequent time-pressures that prevent healthy discussions.
Another good reason to write a great bug report is they can be used as test cases further down the road. If you mange your bugs in a tracking tool you should be able to label them to include in an acceptance pass, BVTs and regression testing. Some of them you could even automate. This will save you lots of time in future releases so a very good justification for taking the time to write it up correctly. You may also be able to use them on other projects if they are standard enough like field testing. You can even use them in your testing documentation without have to re-write them for every project. I have found its best to write bugs where any user could reproduce them no matter what there computer experience is.
ReplyDeleteArrrrrrgg! Good question, a poorly written bug report, (in my opinion) does not include specific details such as a starting point for the developer to repro from. "Open application" could have the developer choosing from a number of ways to open it. And possibly missing the bug completely because the steps did not detail the path to open the bug " Open Application from desktop icon", gives the detail and correct path for a good bug report. The balance of detail is essential for me as I write bug reports. 10 months ago when I started in this industry, My bug reports started with 1. Turn Computer on. As I write more and more bug reports, I start to learn my audience and understand the developer knows how to turn her computer on, and that detail may not be needed in this particular instance.
ReplyDeleteAs far as time spent crafting a great bug report, VS finding more bugs. If I am spending too much time writing a bug report( and trust me, in the beginning you will) I ask for assistance or an opinion. Lucky for me I have a team that is willing to take the time for my questions : ) But overall I think, a well written bug report is worth the extra time.
"a well written bug report is worth the extra time"
ReplyDeleteHow MUCH time? Not all bugs are created equal. Is it better to investigate a bug for three hours or to find 10 more bugs in that time? What factors influence your thinking on this?
In my experience, If I cant repro a bug 3 times, (under 10 minutes, maybe longer in some situations) I make a brief note and desription in a notebook I keep next to me and move on. This way, even though I am unable to reproduce it, it does not become lost or forgotten, and I can continue testing without too much time lost investigating. (sometimes those notes turn into big hairy bugs with sharp pointy teeth!)
ReplyDelete