How do you manage bug reports and feature requests?

Posted by Magnus Unemyr on Aug 26, 2015 11:10:26 AM

Most software developers use version control systems nowadays, to bring traceability and structure to source code changes over time. But, many development teams don’t appear to be equally up-to-speed with a structured way of managing bug reports, bug fixes, feature requests and other to-do items.

Some teams I have been in contact with record this type of information in Excel, or even Word documents, on a shared network drive. While this strategy may work, it is definitely not the best way. If you don’t use a bug database system like Trac, Mantis, JIRA or Bugzilla already, you should make it you first priority to look into this. What is the cost and what are the benefits?


First of all, many of these tools are open-source and free of charge. Once installed on a server, they provide a web interface where all project members can query the project status, submit new bugs or feature requests, and change the status of various items in the database.

An issue management system should minimally allow you to record “tickets” of different types:

• Bug reports
• Feature requests
• Other to-do items

These systems typically allow you to define project categories, where a ticket can connected to a particular part of your project; for example, the networking module, the user interface, the hardware board, the user manual, or any other product component that makes sense for you to track individually.

The administrator can also define the urgency or priority levels that can be assigned to tickets, for example Critical, Important, Medium, Unimportant or Trivial.

You should also be able to define project milestones, which often translates to software version releases, like Beta 1, v1.0, v1.1, etc. This allows tickets to be connected to certain software versions or releases.

With the project categories, priority levels and project milestones defined, team members can start to add bug reports and feature requests with the correct metadata tagging (urgency, where in the project it belongs, what software version the ticket applies to, etc.).

A great use for issue management systems is to add all the bug fixes and new features that is planned for an upcoming release, into the corresponding milestone/version. That way, everyone knows what work tasks there is to do in a particular release.

As bugs are fixed and features are implemented, they are ticked off, and this is immediately visible in the various database reports. You can for example see what work tasks remain to do in an upcoming release, and what work has already been completed. When the release is ready, the list of completed work tasks is a fantastic source of information for the README file you probably want to attach to the release documentation.

In fact, the issue management system is the back-bone of many weekly team meetings. Many development teams center their weekly project meeting around the issue management system, and discuss things like:

• What is the progress since last week?
• What work tasks remain?
• In what order should we do the work tasks?
• What new bug reports have been submitted?
• What priority should new bug reports and feature requests get?
• Should any bug reports or features be moved to a later release?
• Who should be assigned to do what work task?
• Etc.

Using the (often free) issue management system clearly gives many benefits, including:

  • Being the centerpoint of the weekly project meeting
  • Being a great work planning tool
  • Traceability of what bug fixes and features were implemented in what version
  • What bug fixes and features are planned for the various upcoming versions?
  • How should we prioritize new bug reports and feature requests?
  • Who did what?
  • Who should do what?

If you don’t use an issue management system like Trac, Mantis, JIRA or Bugzilla already, I strongly recommend you start right now! In case you don’t like to use a separate web interface in a browser, you can look for a professional C/C++ IDE with a GUI client built-in.

Atollic TrueSTUDIO for example have great support for common issue management systems, with built-in GUI clients for Trac, Mantis and Bugzilla. Using the corresponding Eclipse perspectives, you can add, update and query the database right from within the Atollic TrueSTUDIO IDE.

There is even a built-in feature to take a screenshot, for example of how the debugger looks when you found a bug, crop the image and annotate it with arrows and text, and attach the retouched screenshot as a file attachment to a bug report! There is even pop-up notifications highlighting when other team members add or change status of tickets.

To learn more on what advanced embedded IDE's can do for ARM Cortex developers, read this white paper:


ARM Development White Paper - TrueSTUDIO

Topics: Atollic TrueSTUDIO, Embedded Software Development