1. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
1 z 12 2006-04-04 13:15
About the Autor
Ireneusz Tarnowski is doing PhD
studies at the Institute of
Engineering Cybernetics,
Technical University of Wrocław
and works as an administrator in
the Centre for Networking and
Supercomputing.
To contact the author:
ireneusz.tarnowski@pwr.wroc.pl
Creating your own bug tracking system for IT
projects
During an IT project's lifetime, there always comes a moment when we believe that the project is
finished. At that moment, one of the most important phases of the project begins: testing. Only after
thorough testing can the deployment be performed. It is obvious that developers test their code
during coding, but even after faultless coding, our application is prone to contain errors,
shortcomings, or may be inconsistent with the specification. To prevent the deployed product from
containing errors, in-depth testing is required.
During an IT project's lifetime, there always comes a
moment when we believe that the project is finished. At
that moment, one of the most important phases of the
project begins : testing. Only after thorough testing can
the deployment be performed. It is obvious that
developers test their code during coding, but even after
faultless coding, our application is prone to contain
errors, shortcomings , or may be inconsistent with the
specification. To prevent the deployed product from
containing errors, in- depth testing is required.
Work methodology during project (application)
testing
There is nothing worse than asking the final user to do the testing. A good product may be deployed
only after it is tested by a group of professional testers and a closed group of beta-testers, who will
check the functionality. A group of users testing an open source project can often be opened,
meaning that any one can become a tester. They may use the software, bearing in mind that it is far
from being perfect. Any errors should be reported back to the authors. In this way anyone can take
part in any project and software can evolve towards being stable and completely tested versions. If a
certain project is to be developed , a free communication between users and authors should be
maintained. Not only errors, but new enhancements should also be reported.
How to deploy a project-application for communication between authors, testers and users
Software developers can use bug tracking / issue tracking applications . Bugzilla and Mantis Bug
Tracking System are the leading systems nowadays . These two are big projects, which aid software
testing and development processes. Bug tracking systems, depending on their configuration, allow
for:
reporting of bugs by an open group of users,
creation of user groups; many groups may be created with different tasks and privileges and
information access rights,
assigning roles to users: some users can only read issues, some can report, fix or manage
them,
creation of a project management hierarchy and managing users,
communication between certain users or user groups via e-mail or project message - boards,
2. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
2 z 12 2006-04-04 13:15
viewing of an issue's history; an issue's changes, users' communications and project changes.
The above list of functions is not complete. Often, the sky is the limit. Using the Mantis system to
develop a web portal is a good example. The system works as a platform for information exchange
between developers and the people responsible for extending the portal's functionality. One of the
main reasons for using the system is a distribution of employees. A need for a solution to a problem
is submited to the leader of the developers. They may assign developers to this issue immediately,
or start a discussion with the submitter. A group of developers can communicate through the system
by sharing information, code and any other materials necessary to solve the problem. After the work
is completed, the submitter can check the solution and close the issue or send it back to the
developers with more comments (issues). All the time, the issues are being monitored by a
managing person, who has broad privileges (they may close an issue if a solution is not required;
they may assign more developers to an issue to solve it sooner). The system is available only to a
small group of users (it is a closed project). Although the above model uses only a part of the bug
tracking system functionality, it presents a possibility of its wider use.
Is it worth having your own application?
The existing solutions can overwhelm one with a great number of functions and configuration
options. We often have some specific requirements related to bug tracking / reporting, for example,
a possibility to estimate the time required t o fix a bug or a way to measure and collect the time
spent on fixing the bug (from reporting to closing the thread ). In such cases, when no existing
system can fulfill our requirements, we have no other way than to create our own. Designing,
coding and deploying a bug tracking system should be easy for an experienced developer. The pros
of such a solution are:
precisely specified functionality that matches the requirements,
an appriopriate user interface,
no useless additional functionality, found in out-of-box solutions.
Designing your own application is worth thinking about.
Designing your own bug tracking system
Designing such a system should begin with an in-depth analysis of requirements.
Specifying the functionality for your own system
Aim: reporting and tracking bugs in IT projects. Three separate, main parts of the project can be
identified : a part related to the users, a part related to projects and a part related to issues.
For users:
The system should allow users to register themselves. The registration has to be confirmed by
e-mail.
Each user is assigned a role, which defines a set of privileges to perform actions in the
system.
Users' roles:
viewer: can view registered bugs,
3. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
3 z 12 2006-04-04 13:15
reporter: can view registered bugs and can register new bugs,
developer: can view registered bugs, can register new bugs, comment on issues, fix
bugs and close threads,
manager: can view registered bugs, can register new bugs, comment on issues, fix
bugs, close threads and manage the users in one project,
administrator: can view registered bugs, can register new bugs, comment on issues,
fix bugs, close threads and manage users and projects.
Users are required to provide basic data during registration. They are registered as registers.
The Manager assigns users to projects. They can: change a user's role, edit a user's data,
block users and can create new users with appriopriate data and roles.
User's information (data, date of creation, login dates) should be kept in a database.
The Manager can view data (only for those users that they manage, i.e. only those users
belonging to their project.
One user can be assigned to many projects. If they are assigned to more than one project, they
need to choose the project they want to work with after logging in.
The Manager configures events that result in sending an e-mail (they also define who should
receive the e-mail). The project's status change is an example of such an event.
The Administrator can do all that the manager can. Additionally, they manage all projects
and has access to global configuration options.
Project part:
A Project allows for registering and solving problems from a specific domain (i.e. a certain
web site).
Projects are managed by an administrator. They create new projects, blocks (never deletes)
old projects, assigns users to projects with appropriate roles; when the project is finished,
users assigned to it lose their assignments.
Every project needs to have a user with a manager role.
Issues part:
Each issue contains:
priority: low, normal, high, urgent, critical;
status: new, returned, accepted, done, confirmed, closed;
category: proposal, insignificant, text, fix, small, important, crash, blockage;
An Issue (error) can be reported by anyone, who has permission to do this. The issue is
reported by filling in a form with appropriate data (title, contents, priority, problem solving
deadline, additional information, upload of max. 5 files).
The Issue is registered in a database (all information and the registration date). An e-mail
with the issue's content is sent to the project's manager and all developers.
4. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
4 z 12 2006-04-04 13:15
Every issue has a specific status. The Status can be changed by the manager or a developer,
after performing appropriate actions; according to the logic.
Every issue has a certain category.
The developer defines the timings and costings of the bug fix and adds a comment; a
proposal of problem solution (the issue changes its status to returned. Everyone assigned to
the project receives information about the return of the issue. Next, the reporting person can
comment (add their own thread to the issue's history). The information exchange process
between the reporting person and developer can last until the developer's proposal is accepted
by the reporting person (the status is changed to accepted) or the issue is withdrawn by
changing the status to closed. After fixing the bug, the developer changes the status to done
and reports the amount of time that was necessary to solve the problem. The reporting person
checks the fix and changes the issue's status to confirmed. At that time the issue's thread is
closed (status: closed).
After closing, the issue can be altered. The issue's history may be viewed; all comments
(who, when, contents), status changes and time spent in a certain status.
The project manager can view the state of the system; they can view all issues (chronological
order, reporting person, current status). They can view an issue's history. They can filter
issues (e.g. only active, only closed, oldest active, etc.).
Selecting the system working environment
The basic assumption, that stems from the distributed character of the team (users), is application
availability. It should be available on many hardware and system platforms and it should utilise the
computer network is an optimal way and be easy to use (having a user- friendly interface).
You should assume that the project will be used by people possessing only basic knowledge. It
often happens that people reporting errors (or enhancements) are final users, who have no technical
knowledge. From a technical point of view, our application should be highly portable, because we
(and other users) would like to install it on different platforms. Taking all the above aspects into
consideration we choose a web application as a working platform. A MySQL database is chosen
because of its popularity , ease of use, availability and low costs. The application will be written in
the PHP scripting language.
Since we know the project ' s functionality and environment, we may begin work.
Designing the database
The first step is to prepare an appropriate database. This database will contain all information
related to our application.
The database needs to have tables that will contain information about: users ( bt _users), projects
(bt_projects), issues ( bt_issues), comments (bt_comments), files ( bt_files), configuration
(bt_config, bt_issue_privileges) and additional relations (bt_project_user_relations). All tables
have fields that are required to store necessary information. Fields and their types are chosen in an
optimal way. Table names, fields and relations are shown in Diagram 1.
5. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
5 z 12 2006-04-04 13:15
Diagram 1. Database tables and relations schema
Such a database is a stable back-end for our application. We can extract all necessary information
by using appropriate queries.
Helpful OOP
When writing code for the project we will use new functions available in PHP: the new object
model (PHP 5 or above) and MySQLi ( MySQL Improved ) class, that improves communication
with a MySQL database. The object model will help us create coherent and hermetic code. The pros
will be visible later when good organization of code is required to extend and modify the
application. The classes that should be created first belong to the communication layer (lower):
database class (connections, queries, results),
interface class (interface creation, handling display elements and form elements),
mail class (sending e-mail).
Next, the application functional layer (higher) classes should be created. These classes contain all
information and handle all events related to certain objects (i.e. value modifications, insertions,
value change validations, etc.). Examples of such classes are: issue submit class, user class or
project class. The division stems from the fact that, at a certain moment the application is working
in the context of user, project, database and sometimes issue or mail.
Application and database security is very important. User privileges verification (submitting an
issue, adding a comment, adding a file, changing status, etc.) is performed in the application layer.
Additional security mechanisms should be used: session, encrypted passwords (or hash functions, at
least), user information verification, input data verification (this verification should be applied to all
external data). Security elements will be implemented in different classes, depending on the
function (form data validation will be performed in the interface class, user privileges verification
will be performed in the user class, etc.).
6. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
6 z 12 2006-04-04 13:15
A user-friendly communication interface for our application is a must. Our project depends on the
clarity of presented information and an intuitive GUI. Functionality influences the success of the
project; the best example is the Google project.
Deployment
Thanks to the basic assumptions concerning the working platform (meaning PHP and MySQL)
deployment (installation and configuration) should be carried out without any problems.
Application files should be copied to the appropriate folder on an HTTP server (ie. Apache ). Next,
a database should be created, along with a user who has rights to that database. The next step is to
execute an SQL script file that will initialise the database (all tables and basic users will be created).
Finally, the application can be configured through a configuration file (database name, user name,
password, database server name). Additionally, write privileges should be given to the folder that
will store user files. After performing all the above steps, the application is ready to launch, short of
configuration and work.
Configuration
Our application should be highly configurable if we plan to find a lot of users. Global configuration
should include:
general information about the application (server address, service name, application openess),
e-mail configuration (addresses, mail servers, additional rules),
initial user parameters.
Privileges configuration (defining what actions a user can perform, dependant on project status) is
also important. After initial configuration we can start working with the application.
8. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
8 z 12 2006-04-04 13:15
Diagram 3. Privileges configuration
Who am I: an administrator or a user?
The very first thing you should do after starting working with the application (being its
administrator) is to create a new project and assign users (registered or fictitious) to it. Next, you
should familiarise yourself with the user interface, functionality and all administrative functions,
being logged in as an administrator.
10. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
10 z 12 2006-04-04 13:15
inaccessible from other accounts. This general rule can also be applied here. Although you can
report bugs or track issues as an administrator, these actions should be performed as a regular user
of the project. If you require broader privileges, you should become project manager. You should
remember to allow all registered users to use the system.
Diagram 6. User panel - reporting a bug
11. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
11 z 12 2006-04-04 13:15
Diagram 7. User panel - viewing an issue's thread
Being a regular user, you can only perform actions that you are permitted to. The system will
provide all functionality that had been planned.
What next
If you want to extend your application, you might want to think about:
12. SDJ http://en.sdjournal.org/?module=products&moduleAction=printArticl...
12 z 12 2006-04-04 13:15
On the net
http://www.mantisbt.org/
Mantis Project Bug Tracking
System homepage
http://www.bugzilla.org/
Bugzilla project homepage
data (information) export/import,
support for the XML standard,
localisation,
automatic report generation,
presenting information ready to print.
The list above is by no means complete. It shows the possible ways of extending the usability and
competitiveness of your application. You can extend your project easily if you incorporate a
modern way of coding (object-oriented).
Summary
Bug tracking systems are becoming more and more
popular due to their usability. Nearly everyone is aware
of the need for testing and interaction with the final user.
Our application, by being flexible and user-friendly, can
be tuned to meet the requirements of an individual user.
A clear and consistent user interface results in an easy
and efficient working environment. We have shown that
the fast creation of our own first-class application is
possible.
If you find an error and know how to inform the author, do it. Do not perceive it as malice, but
rather as help in developing the software. Allow others to report errors to you. Launch your own
bug tracking system and allow others to communicate with you; even create your own group of
testers and interact with them through your own platform.
This article does not contain all the available information about bug tracking systems. We hope that
some readers will continue to experiment and create their own applications. Let the aim be:
understanding by doing.
This article is based on experience gained during development of the Issue Tracker application by
Wojciech Urbanowski and Tomasz Klin.
