The following is a general comparison overview of Bug tracking tools. It is focused particularly on the technical aspect. The aim is to help you to select the best tracking system that meets your requirement. Click on the link for a more detailed comparison between Bugzero, Bugzilla, and Gnats.
System Architecture:
Many old bug or defect tracking systems are client server based. You need install the server, and each user need install the client software. If external users were involved, it could be problematic because of issues like firewall etc. Also, it is not always feasible to install client software.
Newer systems are more likely web browser based and no client software need to be installed (except a browser). A web-based bug tracking system is especially attractive if your users are located in different locations and are connected through the internet.
For a web-based bug or defect tracking system, make sure it supports the browsers your users are using. Be aware that many systems support only IE.
Server Operating System:
Most commercial bug tracking systems are Windows based. In such a case, it is likely that it requires an NT/2000/XP server and a SQL Server database. Note that, a Windows XP Professional may not be sufficient, instead, a server may be required.
Most free bug or defect tracking systems are Linux/Unix based, and may not work as well on Windows. It may also require more technical skills to install and setup the system.
When people say their system is cross-platform, you need make sure they meant the server. Only a very few bug tracking systems are really cross-platform (with the same code base). Some vendors claim to support multiple OS, but they have completely independent versions for each OS and that results in higher costs for the vendor and therefore higher price for the end users.
Backend Database:
Most bug or defect tracking systems require a backend database, but a few are file based. In the latter case, make sure it scales well. If someone tells you that a file based system is better than a database, think twice.
For Windows based systems, database selection may be limited to only Access and SQL Server. On the other hand, some free systems may lock you into just one database, notably MySQL. Only a very few bug tracking systems are really cross database systems.
Be aware of any bug tracking software that uses non-standard proprietary databases. They cannot be better than the public, commonly used database systems.
Language Support:
Many bug tracking systems do not support localization, particually, Asian langauges. Note that, it involves the web interface, the data, and the email notification.
If you do need localization, you should find a system that can do that easily.
Web Server:
For Windows based bug tracking systems, most likely it requires IIS as the web server.
For Java-based bug tracking systems, a Servlet or J2EE server is most likely required. There are many high quality servers you can download for free.
Programming Language:
Most of the bug tracking systems are written in either c/c++, or perl/php, or Java.
Depending on your IT environment and skill set, the programming language may be relevant in selecting your system. For example, if you are developing Java software, it may make sense to use a Java based bug tracking system.
Version Control Integration:
Some bug tracking systems have the capability of integrating with source control systems such as CVS, Source Safe, etc.
Be aware of the limitations, and make sure it does the things you want.
Installation and Configuration:
A bug tracking system is not a desktop application and it rarely works out-of-the-box. It is not uncommon to spend a few hours to setup such a system, and then more time to customize it.
However, if you need only a lightweight bug tracking system, a heavy, complex, can-do-everything system is certainly a over kill and it may do more harm than good.
Maintenance and Support:
A bug tracking tool is not a super complex software system, but from time to time you may need technical support. As you certainly know, in most cases, the error messages from these systems are always cryptic, and you won't be able to solve the problem on your own.
How is the error handled in a tool is far more important than you might think. You as the administrator may want select a tool that you feel comfortable to work with.
When support is needed, it is always urgent to you, but not necessary to the vendor. Before you purchase the software, you should ask what is the response time for support.
Features:
Simple is the key here. The system must be simple that people like to use it, but not so complex that people avoid to use it. You might not want to deploy a tool that requires serious end user training. It is really not the initial training, rather the on-going support needed from your end users that you should be concerned with.
Yet it should be flexible and configurable enough to satisfy your business needs. If you select a tool that cannot do whatever you intend it to do, then what is the use of it?
Cost of Ownship:
The initial cost of a bug tracking system varies from free to tens of thousands of dollars. But be aware that this is not the same as the total cost of the ownership. Some free systems charge a hefty consulting fee for support and you may end up paying much more than you planned.
You should select a bug tracking system based on your needs, not just the price. If you know what you are doing and do not need commercial support, go for a free one if it meets your requirement.
However, if you unfortunately selected a bad one, you better get out of it as soon as possible, because the longer you keep it, the more moeny and time you will have to spend on it.
In any case, spending many days to setup a free system or even weeks or months to create an in-house system makes no business and economic sense, because if you consider the time spent, you are actually paying much more than just buying one.
