Reporting a Bug So It Gets The Attention It Deserves
Have you ever reported a critical bug only to see it get tossed around, and not get attended for a long period of time? Well, the bug report you created may not have made an impression.
Surprise! Even in the world of bug reporting, you need to make a good first impression. So how do you make a bug report make a good first impression? Here is a simple guideline you should always remember.
State the user experience!
When reporting a bug, it will likely get the attention it deserves IF you state the issue from the point of view of the user.
When you encounter an issue and want to report it, remember to describe the difficulty you experienced, or your inability to get a task done, or the incorrect data you got that caused your application to behave incorrectly.
Why? By describing the user experience, the dev team assessing the bug you reported can better understand the user’s pain point and the bug’s impact — and even empathize with the user.
It goes without saying that you must avoid being very cryptic with your bug description. Sure, technical details are important, but you should not start the bug description with technical gibberish. In short, do not make it hard for the development team to determine the user’s pain and its impact.
Here is an example. Which of the two bug descriptions below is easier to understand?
1. “Exception occurred when I entered ‘My Files.docx’ then clicked OPEN”
2. “I am unable to read/write/open a file when its filename has spaces.”
I hope you picked the second :) The second clearly states the challenge the user is encountering. This makes it easier for the dev team to understand the issue in their software and its impact to what the user is trying to accomplish. This understanding will likely lead to swifter actions and accurate prioritization of the bug.
Here’s another example:
“Unable to work in any Chrome browser. The app the does not allow me to login using this browser.”
expresses the problem and what the user is unable to do. Not only can the user not log in, the user can’t do any work at all!
If you are thrifty with words, the above can also be expressed simply as:
“Unable to log into the app from any Chrome browser”
The above two are better than merely saying
“Exception error when loginBrowser() is invoked”.
Seriously. This is when you risk making the developer scroll down his email.
And… there’s a pleasant side-effect
By reporting bugs from user’s perspective, you are implicitly educating the dev team how people are using their software. The dev team might have never considered the use case reported, and you opened their eyes. Voila, free education!
But please… do not be dramatic!
Always report the issue you’ve encountered based on facts and your observations only. Avoid using words that could artificially inflate the importance or urgency of an issue. In short, do not add unnecessary words or descriptions for the sake of getting attention from the dev team.
The rule of thumb is you should report an issue so they get the attention they rightfully deserve, and not to merely get attention.
By being user experience-focused when reporting a bug:
- You help the dev team understand and empathize with you or the user
- You help the dev team determine the correct priority of the bug
- You help educate the dev team how users are interacting with their software
- And the issue you’re encountering, if critical or urgent, will get the attention and action it deserves!
Now that you got the development team’s attention, there are more info you can provide for them to investigate and address the bug sooner. This is the topic of a later article. Stay tuned!