Working with different software development teams over the years, it always amazed me to see the number of teams that use the same bug tracking tool to track requirements or customer feature requests and sometimes even support incidents.  I don't mean a tool that was designed to track the different types of items, but rather a tool designed just to track bugs.  To distinguish between the different item types, many teams use an “item type” field to determine if an entry is a bug, a feature or a support call.

I've never thought this was a good idea.  First, the type of information you want to track for each item type is vastly different.  For example, having Repro steps for a feature makes absolutely no sense, while having an executive sponsor for a defect makes no sense.  You might want to capture the details of a user's environment who is reporting a bug, while again, this information is completely irrelevant for a feature request.  Likewise support teams will often want to capture every single call or support “incident”, even if incidents are similar or duplicates of one another, as long as they are from different customers.  To a software development team, having hundreds of duplicate entries in the bug database is as close to a nightmare scenario as you can possibly get.  Each of those duplicate items will have to be tracked, verified, rejected, marked as duplicate or closed.  The fact is, each of these item types are very different and they are used by different roles within the development team.  Feature requests or requirements are used primarily by system analysts and product managers while bug reports are primarily used by testers and developers.  Support incidents are mostly used by help desk teams and support personnel.  Any tool that tries to combine all the item types into the same bucket will inevitably disappoint its users.

For the design of Axosoft's OnTime, we've always believed in a separation of church and state.  Bugs or Defects have had a completely independent tab from Features or Requirements.  Each have their own workflows, custom fields, security, filters and so on.  We later introduced team member Tasks that allow users to keep track of an independent (and mostly private) todo list.  Tasks might have nothing to do with a defect or feature in the system.  It might simply be to install a new version of a particular software - it's just something that needs to get done.

But of course there is a lot of goodness that can come out of using the same tool for tracking bugs, feature requests and support incidents.  Users want to go to a single location for all related information and they often have to communicate about a particular support incident, feature or bug with a team member of a different role.  There are a number of reasons to use the same system to track all of the above information:

• Single sign-on to track all project related information
• Easily communicate between team roles (analysts, developers, testers and support)
• Search for related bugs, customer requests or incidents, especially helpful when on a support call
• When deciding on new features, product and program managers can quickly examine the support incident list to see the most common types of incidents
• Often times a new feature request or bug report comes from a support incident.  Having the same system allows for a user to easily create a new bug or feature request from an incident.

Integrated Help Desk in OnTime 2007

With the introduction of OnTime 2007, Axosoft is adding incident reporting capabilities for help desks and support teams.  This feature allows for a single, fully integrated solution to track issues, bugs, feature requests and of course, support incidents from a single, integrated solution.

(OnTime separates Defects, Features, Tasks and Incidents for a better User Experience)

(OnTime allows for renaming of item types to better suit each environment)

(OnTime also supports localized languages for maximum flexibility)

There are a number of things that are different about the incident tracking capabilities of OnTime 2007 from its defects, features and task cousins.  First, incidents are customer centric, meaning that the first thing you do when creating a new incident is to associate it with a customer.  You can even create a new customer or contact directly from the add new incident feature.  Additionally, incidents have escalation and a few other features that make them unique.  I covered some of the unique functionality in my Top 10 OnTime 2007 Features blog post.

One thing that's nice with each of the OnTime item types is that you can quickly convert an item from one type to another using the “Copy to [X]” feature, where “X” is one of the other item types.  For example, if a support incident is really a bug that has never been reported before, you can quickly create a new bug entry from the support incident entry.  Just use the right-click context menu and choose to copy the item to a bug, like so:

(OnTime items and incidents can be quickly copied to another type)

We'd love to get your feedback on the new Help Desk software functionality of OnTime 2007.  If you hadn't already heard, the Beta 1 downloads and hosted are all available from this link:

Download OnTime 2007 Beta 1 or Try OnTime 2007 Hosted Now

Let us know how to improve the integrated helpdesk functionality of OnTime 2007.