7.1. Tool Requirements At a minimum, a tool for tracking bugs needs a way to uniquely identify each bug and somewhere to store the information that describes each bug. The word bug is used here to refer to both an actual bug in a product and the information about a bug that is stored in a bug tracking system. Bug tracking tools usually store this information in a database. Most tools add the ability to generate reports in various file formats. The contents of these reports are often the results of queries that have been run against the underlying database. Sometimes bugs have states assigned to them, and each bug's state is changed as work is done on the bug. Other information that is often recorded with a bug includes who found it, who is working on it now, which releases the bug exists in, and which releases it was fixed in. There are a number of characteristics to look for in any bug tracking system:
Easy to enter new bugs -
There should be a minimum number of fields that have to be filled in, just enough so that if any of them were empty, then the entire bug would be useless. These required fields should be the easiest ones to find on a screen or in a list (and simply making the field names red instead of black doesn't cut it for color-blind people). You should be able to leave the screen to copy and paste text from other screens, and return to find the screen just as you left it. Drop-down lists can help ensure that data is consistent, but they should not be allowed to grow too long. Fields that aren't available should be disabled, not just made invisible. If there are obvious choices for whom a bug should be assigned to, then these should be filled in automatically. You should also be able to attach other files to a bug.
Easy to change the state of a bug -
The different states that a bug can be in varies widely with different products and projects, so a convenient state diagram that shows how bug states are expected (and permitted) to change is very useful. If bugs are allowed to change states only according to the state diagram, then it's helpful if the bug tracking tool suggests only the valid states for changes.
Easy to change many bugs -
The ability to change a number of bugs with a single operation can save a lot of time, especially if the list of bugs is the result of running a report.
Easy to review a particular bug -
Given a particular bug identifier, you should be able to view and edit that bug quickly and intuitively. All of a bug's information should be accessible from a single screen of the UI.
Easy to watch a bug -
It should be easy to become aware that something in a bug has changed. Email is the usual way to notify people about this. It should be easy to change when and how different groups of people are notified. Notifications may be related to groups of bugs or to changes in the state of bugs.
Easy to search using brute force -
When all other ways of finding a particular bug fail, you should be able to search all the text fields for a given string. It may not be efficient, but when you are stuck, you really need to be able to do this.
Easy to trace the history of a bug -
You should be able to see how a particular bug has changed over timewhat changed, who made the change, and when. Snapshots of the bug at each change and a list of the differences between the snapshots are both useful.
Easy to connect to source code changes -
If a bug tracking system is integrated with an SCM tool, then you should be able to find all the changes to the source code that are related to a bug or multiple bugs. This could be reported as the affected filenames and their versions, the differences between versions, or the changesets.
Characteristics you should look for that relate to using the bug tracking system to manage a project are:
Easy to generate reports -
How easy it is to generate different reports is often a major factor in people's perception of how easy it is to use a particular bug tracking system. It should be possible to generate simple reports by using a simple interface. It should also be possible to generate more complex reports with AND, OR, and XOR Boolean operations, selection of multiple values, and range comparisons. You should be able to save all reports, along with text explaining the purpose of the report. Formats for reports can include HTML, comma-delimited text, XML, Microsoft Word, and PDF.
Easy to produce historical reports -
Not all bug tracking systems let you produce reports about how the bugs have changed over time. These kinds of historical reports are very useful for seeing how a project is progressing.
Easy to connect to a schedule -
The list of which bugs should be fixed for a particular release should be straightforward to enter and to create reports about. If one bug depends on another, then that also should be made very obvious. Some projects like to be able to have project members vote for the bugs that they really want to be fixed, which can help when assigning bugs to planned releases.
Desirable features that are more closely related to administering a bug tracking system include:
Easy to modify the definition of a bug -
The administrators of a bug tracking tool will probably need to change the different fields that make up a bug. This should be straightforward, with clear documentation about what kind of data is expected in each type of field that can be added. Adding new fields to UI screens should be as intuitive as possible. Removing a field should also be integrated with the report and screen design areas of the bug tracking system.
Easy to modify the workflow -
It should be easy to change the states that a bug can be inthat is, to change the names of the possible states and also how the states are related to each other. Adding or removing states should also be possible.
Easy to manage the list of users -
Many companies already have their users definedfor instance, in an LDAP server. Bug tracking systems that can work with existing lists of users make maintenance easier. There should at least be a way to import a list of users, so that the administrator doesn't have to enter each one manually.
Scalable -
As the number of bugs, groups, and users in a bug tracking system grows, the interface design must also scale well. Drop-down lists with hundreds of users don't work very well. Searching text fields may become painfully slow. Backups may become more than an overnight job. Additional features to help with detecting duplicate bugs also become more necessary as the number of bugs increases.
Accessible through external clients; good API -
You should be able to read and modify data in the bug tracking system from outside the GUI or browser. This is a generally useful ability (e.g., for adding the latest build label to the bug tracking system as part of an automated build process). A well-considered and well-tested API, beyond just writing SQL statements, is a good sign.
Easy to change the text displayed -
It should be easy to change the text that is displayed onscreen for usernames, release numbers, and other field names. This is partly to help localization and customization, but also because product names can change, so embedding them directly in a database field name makes maintenance harder than is necessary.
Easy to back up different parts of the bug tracking system -
You should be able to save copies of reports and UI screens before modifying them, in case of errors. This also allows you to design complex reports and screens on a development system and then import them into a production system, rather than having to re-enter them by hand. Backing up the actual data in the bug tracking system should be possible on a live system and easy to automate.
The features listed so far in this section are the positive requirements for bug tracking tools. The following is a list of some general issues with bug tracking systems that come up again and again in practice. More specific annoyances, and ideas to help work around them, are described in Section 7.3, later in this chapter.
Huge attachments -
Many tools claim that the size of file attachments that can be added to their bugs is limited only by the underlying filesystem or database. That may or may not be true, but you should check how the performance is affected. Section 7.3.2, later in this chapter, has some more ideas about cleaning up your data to help with this.
Spam magnets -
If you create a public email address for customers to send bugs to, you risk filling your bug tracking system with spam when the address falls into the wrong hands. Good spam filtering will help stop most of this, but be sure you can delete information from all the fields in your bugs.
Mystery data formats -
Migrating from one bug tracking system to another is often very tedious, even more so than with SCM build tools. If the data is in an open format, and if there are published schemas for each tool's database, then the process becomes somewhat easier. Before you add data to a bug tracking system, consider how you would extract it if the system failed to perform in some way.
Internationalization -
Some bug tracking systems don't handle non-Latin text and other characters well in their input fields, or even in the names of users. Many are not localized for any language except English.
Default values -
If no data was added to a field, what value does that field have when you want to search on it? If a field is added or removed, how does it appear in historical reports? Not surprisingly, the classic database issues of nulls and defaults also exist for bug tracking systems.
Databases need administrators -
If a bug tracking tool uses a complex database such as Oracle, then there will probably be occasions when Oracle administration will be a necessary skill for the tool administrator. Make sure this is clearly understood from the start and arrange for consulting and training if the necessary skills aren't available within the project.
Multiple platforms -
Different people will want to use the bug tracking system from different platforms. Since supporting client applications for multiple platforms is a lot of work, many bug tracking tools have chosen to use web servers and browsers instead. This is mostly portable, but not all browsers will work with complicated web pages, and many browsers don't do very well at displaying XML or HTML text when it's entered as data for a bug. A related problem is that some users, and most system administrators who are integrating a bug tracking tool, will want to use CLI commands. The CLI ought to work uniformly across the different supported platforms, but in my experience it often doesn't.
|
