Writing is easy, but writing clearly is hard. When it comes to write bug report... well, writing seems to get even harder, as far as the IT professional is concerned. In my life as a developer I have seen a lot of bug reports that are either incomplete, or missing critical reproducible steps, or have no explanation of why the results are wrong. Imagine if you were a developer and you got this kind of bug report, won't you feel frustrated? The best you could do is to mark the case as not reproducible and assigned it back to the tester. The tester, would, in turn would, insisted that the bug was there and, well, there went a football-kicking session. Congratulations, you've wasted a few non-productive minutes on just trying to get message across. All these wasted minutes would add up, resulting in a loss in productivity.
There are a lot of resources on the Internet that teach us on how to write a good bug report. I am sure some of the tips here are also available elsewhere. But even though the points are the same, but the presentations differ. So my hope is that for those who haven't know how to write a proper bug report, they can gain something after reading this post. As for those who are already knowledgeable, they would still find the information here useful, or at least entertaining.
- Clear title-- Good title is a must, as the developer should be able to grasp the essence of the bug report from the title alone. If you have a large database, having a clear title will help the system admin to assign bug reports to the correct developers without even reading the whole reports.
- One bug per report-- Report one bug in a single report, no more, no less. If you put in too many bugs, some of the them may be overlooked. To avoid confusion and duplication, please, one bug per report, no more, no less.
- Minimum, quantifiable steps to reproduce the problem-- This is important. Developers need to be able to get to the problem in the shortest time. So the testers' job is to help them to do just that. Testers need to do a few round of testing to clarify the steps, and to be able to reproduce the problems using minimum steps. We the developers will appreciate the extra efforts, really. If the testers can't specify the steps to reproduce the problem, then the developers have to conclude that the bug doesn't exist.
- Expected and observed results-- A bug report should always contain the expected and observed results. A generic description like "This is a bug" is not helpful, because the bug in question is not immediately obvious to the developers. Another reason for spelling out explicitly the expected and observed results is that sometimes the developers don't think that the bug is a real bug. So it is the testers 'duty to explain to the developers what went wrong.
- The build that the problem occurs-- Daily builds are common nowadays. So if the testers don't specify the exact problematic build, developers might have a hard time trying to solve an already-solved problem. That will be a waste of resources.
- Include background references, if possible-- If a bug is related to other bugs, then please include those information in the bug reports. This will help the everyone who reads the report understand the issues at hand better.
- Pictures-- A picture is worth a thousand words! Sometimes words just don't flow; in that case why don't just capture a clear picture that illustrates the problem?
- Proofread the bug report!-- This is very, very important. Now the bug report is readied, but why not just trial run what is written to make sure other people can follow and reproduce the problem exactly? A proofread bug report has a much higher chance of being understood properly by the developers and fixed by them.
- Don't write generic titles-- Don't write titles like "Help!", "What happen?". This kind of titles are devoid of content at best and irritating at worst. So please provide a clear, concise title to your reports.
- Don't use personal communications-- Put everything your know, all the latest developments in the bug report. Don't resolve the bug privately with the developers. The whole purpose of bug report is to capture all the interaction that is going on so that the knowledge won't be lost. Using personal communication, or resolve the cases privately is defeating very purpose of bug tracking.
- Don't assume that the developers can read your mind-- The developers don't have telepathic ability. Don't ask them "do you get what I mean?", or "you get me?", follow up by a confusing stare. Try your best to express yourselves, use pictures if possible. And don't assume, the developers can only follow things that are written on the bug report, don't assume them that they will do a few sextra teps you think are obvious.
- Don't kick the bug report around! -- We have enough politics in the office already. Using bug report to score political points is detrimental to everyone.
- Don't be rude-- Well, if you can help it :)
That's all from me, anymore?