When creating computer applications we produce bugs. Errors are intrinsic to the human condition: we are not infallible. Either due to misunderstandings, ambiguous requirement specifications or lack of attention to detail, bugs will inevitably be found.
When a bug is detected in an application during early testing phases or in a live environment, it should be reported so the development team can fix it. Usually, the person who finds the bug is not the same person who will fix it. It is important to give as much contextual information as possible when reporting bugs so the developer fully understands the problem and fixes it quickly and accordingly.
To avoid these problems, every bug report should have the following information:
Location of the Bug
Sometimes we use different platforms to access the same application or database. For example, a sales manager may manage sales using a desktop application while a vendor would use a web application on a tablet to create new sales. When reporting a bug, it should be explained which application has a problem and in what environment it was found (beta testing, production, etc.).
Steps for Reproducing the Bug
Users and testers may be tempted to report a bug like, “Adding a new work order to the application does not work”. Although this sentence may give us some idea about the root of the problem, however, if based solely on this information, the developer would need to invest a lot of time guessing how the problem occurred. The developer may not find the bug because the application works when using it in a different way. Explaining the sequence of actions that lead to the problem will help fix it quickly.
Expected Behavior
This may sound like something trivial if both the user and the developer are on the same page. Different ideas of what the application should do will most likely result in bugs, so it’s always best to clarify the expected behavior. Here’s a perfect example: “After creating a new request for a client and clicking on the Save button, it is expected that the new request appear on the requests list for that client.”
Current Behavior
Similar to the last point, just a few sentences explaining the system’s current behavior is ideal: “After clicking the Save button, I got a message saying the request was successfully saved, however, it is not displayed on the requests list”.
A Screenshot Showing the Error
The phrase “an image is worth a thousand words” applies very well to this case. The developer fixing the bug does not see the error when you find the bug. Don’t hesitate to send a picture of the error message.
Other Information that Might Help for the Developer
Listing standard error codes, exception messages, and the type of web browser used when receiving the error (with web apps), etc. may shed some light on the source of the problem. Either a screenshot, a copy of the text with the error or a short description should be included in the report.
Tools to Report Bugs
A bug can be reported in many ways, like sending an e-mail to the developer with the bug report, but it is best to use a tool that centralizes every bug report. These tools usually offer features like bug assignment and progress tracking.
An example of one of these tools is FogBugz which enables any stakeholder – testers, developers or application users – to log in with a username and password to report and track bugs.
Once logged into the system it is possible to see the open bug cases assigned to the each person who will either fix a bug, work on a new feature, test a change/resolution, etc. During the process you can add notes or change the status for each case until it is confirmed that the proper solution was implemented, then the case can be closed.
Finally, FogBugz offer some tools to help create new cases, like a screenshot tool, which enables the user to capture a screenshot from their desktop, create a new cases for it, and automatically attach the screenshot.
Next time you have a bug, avoid the ambiguities and remember these tips to ensure a quick and easy fix.
