In the past month, I’ve had a few different people who are not testers ask me about filing bugs. It always makes me happy when people ask me this question, because knowing how to write up a good bug is the first step towards getting it fixed. The more effectively you write bugs, the closer you will be to getting your problem taken seriously and addressed. Since computing is now so ubiquitous this goes for everyone from developers interacting to sales and marketing people or even end users interacting with support.
Write an effective title
In this day of scanning, bug titles turn into what everyone will look at the most in a bug. In Tracker, they turn into story titles which is the most visible element of a story. It’s worth taking extra time to make sure the title is as succinct yet as informationally dense as possible.
Take pains to write clear steps to reproduce the problem
While some bugs are worth capturing even if you cannot reproduce them, it always helps the person on the other end to understand your bug if you include clear steps to reproduce. I make them painfully obvious, for example:
1. Open the Firefox browser
2. Open this URL: <URL would go here>
3. Click on the big red button
If you can identify elements by their CSS class or ID, that is a great way to make things clearer, if not, do your best to describe what you see.
Include environment information
Which Browser, which Browser version and which Os?
If you are on a device, the name of the device (Asus Transformer) and operating system version will clarify what hardware you are using when you see the bug.
Expected Behavior vs. Actual Behavior
Explain what you thought you would see vs. what actually happened. Often a feature works as the developer or product manager expected or you have uncovered an area of behavior that was not thought about when the feature was designed and coded. For this reason, it is important to separate what you expect from what actually happens.
Screenshots
It is good to include screenshots if something is noticeably wrong. Personally, I prefer a carefully written description as it gives me insight into what the author of the bug was thinking.
Manage your tone of voice – don’t write mean bugs
It can be easy to sound irate or self-righteous in a bug. Testers know this. After you’ve completed writing it up, read for and remove any overly emotional language. This goes for obvious phrases such as, “THIS MAKES ME WANT TO SLIT MY WRISTS,” “WTF” or “Really????????” and also more subtle language. Such language will not get your bug fixed any sooner and will only alienate you from those who can fix the problem. (I have learned this lesson from experience and have written a few mean bugs in my time.)
Don’t assign priority if you can help it
There is a difference between the severity with which a bug impacts your usage of a system versus the priority with which a developer will be able to fix the bug. While it’s well withing range for you to right about how a bug has impacted the application you are using, you are not the one in charge of the development schedule.
Anyone who works on finding and writing better bugs deserves a pat on the back so, here, let me give you a virtual one: <Marlena pats you on the back/>
