Simple bug tracking system using Excel spreadsheet

http://www.mobilefish.com/tutorials/webdevelopment/webdevelopment_quickguide_bugtrac
king.html
Information
For large projects it is recommended to use a more advanced bug tracking tool such as
Bugzilla. For very small projects you can use this simple bug tracking system based on an
Excel spreadsheet.
Operating system used
Windows XP Home Edition Version 5.1 SP 2
Software prerequisites
Microsoft Excel
Microsoft Word
Procedure
1. The bug life workflow is as follow (click on image to enlarge):

2. Create a project folder, for example: C:\myproject

3. Download the bug_report_template.doc into this folder.
This Word document describes what a bug report should contain. The key to making a
good bug report is providing the developers with as much information as necessary.
The more information you supply, the easier it will be for the developers to determine
the problem and fix it.
To create a bug report:
o
o
o
o
o

First create a subfolder with the bug id as its folder name, for example:
C:\myproject\15
Copy the C:\myproject\bug_report_template.doc into C:\myproject\15
Rename the document into bug_report_15.doc
Place all additional information regarding this bug such as screen dumps and
log files in C:\myproject\15
Edit bug_report_15.doc

Column

Value

Description

Bug#

All bugs must have an unique id number.

The ids are sequentially numbered.
The last used bug id can be found in the
bug_tracking_template.xls spreadsheet.

Originator -

The person (also known as a bug reporter) who

has found the bug and created the bug report.
Developers sometimes needs to contact the
originator that is why the originator's email and
phone is helpfull.

Submit
date

The date (dd-mm-yyyy) when the bug report is

submitted.

Summary

A short description (recommened two lines) of

the bug. A more detailed description can be
found in the description field.

Severity

1.6.blocker
Indicates how damaging the bug is and is set
by the bug reporter.
2.7.critical
3.8.major
4.9.minor
7.12.
Blocks development and/or
5.10.
trivial
testing work.
6.11.
enhance
8.13.
Crashes, loss of data, severe
ment
memory leak, performance problem.
9.14.
Major loss of function.
10.15.
Minor loss of function, or other
problem where easy workaround is
present.
11.16.
Cosmetic problem like
misspelled words or misaligned text.
12.17.
Request for enhancement.

Product

If you are developing more than one product,

identify the product in question where this bug
is found.

Component

A product can consist of components. Identify

the component in question where this bug is
found.

Version

In most cases the product is not static.

Developers need to know in which version the
bug is found.

Platform

13.18.
14.19.
h

PC
The platform used when this bug is found.
Macintos

OS

15.20.

Window The operating system used when this bug is

s
16.21.
17.22.
Browser

18.23.
19.24.
1.5

found.
Mac
Linux
IE 6.0
Firefox

The browser used when this bug is found.

URL

If you are developing a web based product,

identify the URL where this bug is found.

Description

Explain in detail what is wrong.

It is often helpfull to list the steps taken to
recreate the bug. Include all proper menu
names, don't abbreviate and don't assume
anything.
After you've finished writing down the steps,
follow them and make sure you've included
everything you type and do to get to the
problem. If there are parameters, list them. If
you have to enter any data, supply the exact
data entered. Go through the process again and
see if there are any steps that can be removed.
Remember to report one problem at a time,
don't combine bugs in one report.
If available, supply any supporting
documentation e.g. log files and screen dumps.

Download the bug_tracking_template.xls into folder C:\myproject.

This Excel spreadsheet tracks all reported bugs. Each time a bug report is created, this bug
must also be reported in the bug_tracking_template.xls spreadsheet.
Only column Bug#, Originator, Submit date, Summary and Severity must be filled by the bug
reporter.
Column

Value

Description

Bug#

All bugs must have an unique id number.

The ids are sequentially numbered.
This field is set by the bug reporter.

Originator -

The person (also known as a bug reporter) who

has found the bug and created the bug report.
This field is set by the bug reporter.

Submit
date

The date (dd-mm-yyyy) when the bug report is

submitted. This field is set by the bug reporter.

Summary -

A short description (recommened two lines) of

the bug. A more detailed description can be
found in the bug report. This field is set by the
bug reporter.

Severity

20.0.
21.1.
22.2.
23.3.
24.4.
25.5.
ment

blocker Indicates how damaging the bug is and is set by

critical the bug reporter.
major
minor
26.6.
Blocks development and/or
trivial
testing work.
enhance
27.7.
Crashes, loss of data, severe
memory leak, performance problem.
28.8.
Major loss of function.
29.9.
Minor loss of function, or other
problem where easy workaround is
present.
30.10.
Cosmetic problem like
misspelled words or misaligned text.
Request for enhancement.
31.11.

Priority

32.12.
33.13.
34.14.
35.15.
36.16.

P1
P2
P3
P4
P5

This field is set by the Software Review Board

where both the project manager and client
decides in which order the bugs should be fixed
in. The highest priority is P1 and the lowest is
P5. Priority is determined by combining
severity (above) with the frequency of the
problem and sometimes business needs (e.g.
fixed advertising campaign date).
37.17.
38.18.
39.19.
40.20.
41.21.

Assigned
to
Resolution

critical
high
medium
low
unkown

The lead developer assigns the bug to a

developer who will be responsible for fixing
this bug. This field is set by the lead developer.
42.22.
43.23.
44.24.
45.25.
46.26.

fixed
Indicates what happened to the bug and is set by
invalid the developer.
wontfix
cantfix
49.29.
A fix for this bug is made.
needinfo
50.30.
The problem described is not a

Status

bug. An explanation can be found in the

bug reports description field.
51.31.
The problem described is a bug
which will never be fixed. An
explanation can be found in the bug
reports description field.
52.32.
The problem described is a bug
which can not be fixed because of
certain circumstances. An explanation
can be found in the bug reports
description field.
53.33.
The developer needs more
information from the bug reporter. The
requested information can be found in
the bug reports description field.
54.34.
The problem is a duplicate of an
existing bug. The duplicated bug# will
be reported in the bug reports
description field.
55.35.
All attempts at reproducing this
bug were futile, and reading the code
produces no clues as to why the
described behavior would occur. If more
information appears later, the bug can be
reopened. An explanation can be found
in the bug reports description field.

47.27.
48.28.
me

duplicate
worksfor

56.36.
57.37.
58.38.
59.39.
60.40.
61.41.

new
Indicates the general health of a bug.
assigned
resolved
62.42.
Bugs that are first opened and
verified
has not been assigned to anybody yet.
reopend
This status is set by the bug reporter.
closed
63.43.
The bug has been assigned to a
developer who will take charge of it.
This status is set by the lead developer.
64.44.
A fix for the bug has been
implemented and it is awaiting
verification by QA (Quality Assurance).
This status is set by the developer.
65.45.
The QA has verified the validity
of the bug fix. This status is set by the
QA.
The QA is usually a (lead) developer
verifying the bug fix and also reviews
the code if it complies to coding,
security and other standands.
66.46.
The bug was previously
resolved, verified or closed but it has
been reopened. This status is set by the

QA or tester.
67.47.
The tester verified the bug fix.
This status is set by the tester.

This field is set by the bug reporter, lead

developer, developer, QA or tester. See bug life
workflow.