In our small team, we needed a tool to track bugs found during the development cycle.
Although many tools currently exist on the market, we needed something very simple,
because we felt that to be effective, a bug tracking tool should allow a developer to
enter a new bug in no time.
As far as I was concerned, I needed no other features, that may be found in other
expensive packages, or even in the beast itself.
That is when I stumbled accross Joel Spolsky's most excellent
Joel On Software that has provided me with
hours of reading at lunch time ever since. I was particularly interested in the article
that dealt with
painless bug tracking.
That was it! I decided to jump on the bandwagon, and developed this small project from scratch.
How to Use This?
Basically, bugz consists of a set of ASP server-side scripts that need to
be processed by Microsoft's Internet Information Server. The data for the bugs are stored
in a Microsoft Access database, but that can easily be changed, because that detail is
centralized in one page.
The following picture shows a sample bug as rendered by the ASP pages. You will notice that
it mimics as closely as possible what I have seen on
bugz is designed to be extremely simple. There is no administration pages
nor any pages not directely relevant to entering bugs. Currently, what you can do is:
- list all bugs in the database
- enter a new bug
- update a bug assigned to you
config.asp contains some options that you will need to check. Make sure
the baseURL variable is set to the address of the application. Additionnaly, you
can set the bSendMail variable to
True in order for e-mails to be sent
automatically when a bug is entered or updated in the system.
bugz was designed to work with small teams. It doesn't use any authentication
scheme. All that is required is to pass along the user login with the URL as explained below.
The main pages for the application are:
list.asp: lists all bugs in the database
history.asp: displays history information for a specific bug
new.asp: allows for entering a new bug in the system
For instance, in your team, John would need to set the main page for the bug tracking tool
in his web browser to point to the following URL:
To enter a new bug in the system, the following URL would be used:
When a new bug is entered in the system, its status is Open and it is automatically
assigned to the module owner, say Jack. Additionnaly, if the corresponding option is turned on
config.asp page, an e-mail is sent to Jack.
When Jack wants to update a bug, he points his web browser to the following URL:
Where 90002 is the bug number. This is the address that is displayed in the first line
of the e-mail that was sent to Jack. Because this bug is assigned to him, Jack is presented
with the history for this bug, as well as with a form where he can enter informations in order
to update the bug.
Upon update, a bug can be assigned to someone else and its status can be changed according
to the rules described hereafter. Again, an e-mail is sent to the new person that now owns the bug.
This goes on until the bug is closed.
- When a bug is open (Open), it can stay open, or be resolved
(one of Fixed, Won't Fix, Not Repro, Duplicate, By Design)
- When a bug is resolved, it can be reactivated (Open) or closed (Closed)
- When a bug is closed (Closed), it cannot be updated any longer
In this article, I have demonstrated the use of a simple, yet useful, bug tracking tool
that is targeted at small development teams. I hope you will find a use for this with
your own teams.
I'm looking forward to reading your comments and suggestions.