Features
Evaluators often get confused when they try to compare between many features in various Issue Tracking Software. This chapter attempts to categorize multiple needed features for a good Web-Based Bug Tracker for incidents, bugs, and operational issues.
Tracker Fields
Fields are required to Track the Bugs or Issues. Some of these fields can be Predetermined (like status or criticality of the issue) whereas some of them can be User-Defined. A software vendor cannot determine all the needs of its customer, so the capability of having User-Defined fields is essential. Evaluators will need to look at the following factors:
- How many User Defined fields are possible, does the vendor offer only a few user-defined fields (e.g., 10) or unlimited user-defined fields?
- What types of fields are possible? Examples of some of the common field types are text-box, pick list, date, yes/no, etc.
- Can you set the default value of a pick-list? For example, suppose you are entering issues on the inventory problems, and most of your inventories are at the Denver location. It would save some keystrokes if you could set the location field to Denver by default on the input form.
- What happens to the previously entered issues when you have changed an item in the pick list? For example, suppose your location has moved from Denver to Colorado Springs, and you do not want to show the location Denver on the pick-list anymore. This change of location will require you to rearrange the pick list. You must make sure that the old issues entered still stay as Denver on your reports.
- Can you make a field mandatory in the input form?
- Can the read/write access be granted on a field to a particular set of users?
Search
Due to the number of issues entered into the system over time, a suitable search mechanism is of paramount importance. The following factors should be taken into consideration:
- Can the system do a full-text search on a particular field? Can it be done across all the fields?
- Can the search be saved as a view so that they can be reused later instead of generating them over and over again? For example, if you often do search in all the resolved issues at your location at Denver, it may be easy for you to save a view and run it every time you want to search.
- How sophisticated can the search criteria be? For example, you may want to know how many issues are open at locations in Denver and Los Angeles in the last two days and are marked critical.
Consolidated view
A consolidated view of all the issues is useful for taking a first look at the Issue Tracking Software. As this is often the first screen users visit at the start of the day, it is important to consider this feature carefully. Some of the points to consider are:
- Can the user (or an administrator) select which columns to view?
- Can the view be sorted dynamically by columns?
Projects and Templates
A company may not be just buying an Issue Tracking Software to track software bugs. It is useful to consider if the same investment allows tracking of many other things like Warehouse Issues, Sales Leads, Recruitments, etc.? Some of the things to consider here are:
- Can the system define projects that can hold issues of a particular domain? Examples of some of the domains are bug tracking, HR employee management, etc.
- Can each project be individually configured?
- Are there canned templates? For example, if you want to create a project to track bugs, is there any template that can set up default fields.
- Can you create and save a template? For example, if you have set up a project by modifying fields for a particular domain, can you create a template out of it to create future projects?
Attachments
Issues and Bugs often require screenshots and other documents. A good Issue Tracking Software should provide a means to upload and view such documents.
Workflow
Issues, when entered in the system needs to be assigned to people who work on them. Evaluators should see if such a feature exists in the Bug & Issue Tracking Software.
Report
The ability to create customizable reports cannot be understated as this is the most important use of the issue and bug tracking system. Some of the factors to consider for reports are:
- Can the fields, search condition, an aggregate condition be selected while creating the report?
- Can the system create charts? Charts are sometimes useful to get a quick picture. For example, the management may want to see the distribution of criticality of issues over a particular period.
- Can the reports be exported to the PDF files, Excel files or Word files?
Archival
Issues in a project may grow large over time, and it may be necessary to archive them to avoid clutter. Some of the things to consider for archival are:
- Can an individual issue be archived?
- Can a project be archived?
- Can issues from a project be copied to another archived project?
- Can archived information be restored on demand?
History
History of edits to a particular issue may be necessary to track as it gives an idea of the changes that had taken place on an issue for a period.
Information Exchange with external systems
This feature is often missed out by evaluators. If the system does not provide imports and export features, users of the system may get locked into the system as they may not be able to migrate their information to another system should they become unsatisfied with the existing system or if the existing company has changed focus or has gone out of business. Some of the points to consider are:
- Does the system has the feature of import and export in comma-separated value (CSV) format.
- Does the system has the feature of import and export in XML format. XML has become a standard of information exchange nowadays and can represent information in a formatted fashion(as opposed to CSV)