Ho to submit a good bug report


Bug reports are the mean of communication between the user (an end user, or a QA technician) that encounters a software defect, and the support guy that will handle the problem (a tech-support engineer, helpdesk, or the software developer).

In the bug-report the user explains what he did and what went wrong.


The first problem on the support side is to understand the report.

People tend to describe things in different ways. Some people like to be very brief and think that the guy that read the report saw the problem as they did. Others tend to write complex sentences. Overall, when we read a bug report, we need to picture what happened in the other side.


The other problem is the luck of information. 

In many cases, the bug is not straightforward (e.g. click on the OK button and system crash). These are the simple problems, which usually do not sneak out of the development rooms. Most problems that pop-up in the QA testing, Beta sites, or in the field, are complex problem. These problems are due to a special situation in the user’s side. This special situation may be a special configuration, a path that the user took (different for the normal path that was vision by the developer), something that the user did or did not do in the path (e.g. he did not check a check-box), or a combination of these things.


The first step for the developer to solve a software defect is to replicate it.

And in order to replicate the problem, he needs as much information as possible.



Another thing that helps the developer is to get information on the actual behavior of the application when (an prior) to the defect.

The best thing that could help him is if he can see exactly what the application did in every step. Because this is very difficult to get, software developer add “log” lines to their code. On every important step that the application take, it writes a log line that the place (in the code) and the relevant objects that affect the step. The logs are very important tool for understanding field defects.

The problem with the logs is that they tend to be very large files (millions of lines), so to attach them to every bug report will be over-kill. Another problem is that sometimes it is very difficult to correlate the user actions with the log-lines.


Another important tool (in some cases) is the sniffer. If the software is a client-server application and the communication uses a standard protocol, than a sniffer can show what the client request and what the server response. A good example is the WEB browser that uses HTTP messages to communicate with the server. A sniffer is a powerful tool but it suffers from the same problems that the “log” has. It is very big and very difficult to synchronize it with the user-actions.


Another major problem that we find in bug reports is that some times the report contains false data. The false data is entered because the user does not always remember exactly what he did or how the application reacted.

This false data may lead us to wrong conclusion and trying to solve the wrong problem.


So to conclude our discussion up to here, we can say that a good bug report needs to be understandable, comprehensive and accurate.


In order to submit this type of report a guy needs a lot of time to gather all the information and write it in a way that it is understandable. He also needs to be very knowledgeable of where and how to fetch the information and needs to remember exactly what he did prior to encountering the defect.

But most end users (e.g. a secretary that is using a CRM application) will not be able to do it.


vLog (Visual Logger) is a software tool that is aimed to solve this problem.

It is a recording tool that runs in the background as a “Flight-Recorder” and records user-actions on specific applications. When the user detects a problem he clicks Ctrl-Ins and vLog sends a bug report (of the x last user actions) to a reconfigured destination (or attaches it to a bug-reporting tool). vLog can be programmed to record HTTP messages (to and from specific URLs) and to keep track of log files. When vLog creates the report it automatically attaches relevant parts of the log files and other reconfigured extra-information to the report.

The developer can view vLog’s report as a serious of slides (pictures) that show the user-actions with the extra-information that is relevant to the action (e.g. the HTTP messages that were sent and received after the user clicked on a button). Or he can be run it as a movie.

vLog enables novice users to easily create an understandable, comprehensive and accurate bug report. For more information and to download a trial version, please see http://www.vapisoft.com/vLog.htm