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