How to find the right bug tracking system and how to use it in our projects?

Question

I was looking for some information on bug tracking best practises, but the Google search on this topic wasn't as hopeful as I wished; I mainly found about software issues such as writing good bug reports, however I found two great discussions on stackoverflow: the first one is about bug tracking best practices and the second one is about redmine best practices.

From project management perspective, what are the best practices to find and use bug tracking systems?

Answer 1

Every project will have its own goals for a bug tracking system. Only you can define yours, but asoundmove makes some good points. To not get too repetitive, I'll just assume you read that answer & jump right in:

1. Make sure your process supports your goals. You'd be surprised how often people pick a tool or implements a process because its 'the best', but eventually no one values it. It provides nothing useful to anyone & it dies.
2. Start small. Effective process change management takes time and you'll have more success implementing small changes over time than trying to design the "perfect" but tracking process and throw it at your team all at once.
3. Consider your bug tracking database may have uses besides the day-to-day resolution of defects. It can be used as a scheduling tool itself, to monitor when you are pushing the team too hard (more defects), or to help estimate future work.
4. If you're going to use it to track tasks, be careful. Common mistakes you can make tracking 'tasks' in a bug tracking system:
   • Too fine detail. Assuming it takes 10 or 15 minutes minumum to write a decent task description, you have to ask how long will this task take? If it's something that could be done in an hour or so, you are adding a huge admin burden on top of every activity you undertake.
   • Vague exit criteria. Defects & enhancements are 'simple' to manage in a bug tracking system - it's easy to know when you're done. Depending on your process, someone validates / confirms / tests that the requested change was made satisfactorily. It's easy to write 'tasks' that have no clear mechanism to know if the task was accomplished correctly, sufficiently, or completely. These tasks become an administrative burden.
   • Duplication of effort. Are you capturing tasks in a bus tracking system, but also reporting them in status reports or as tasks in Gantt / schedules?
5. All change requests, whether defects, enhancements or tasks tied both to some kind of customer requirement (which might also be captured in the same database) and closed change requests either have a resolution explaining why no change will be made or a link to the changed artifacts. Preferably these changed artifacts are checked into your revision control system: source code, build & initialization files, tests & documents.

Answer 2

Brian, I have been in your shoes. My main recommendation is: "Forget about Redmine, for now, focus on your process"

After you have a good process for bug tracking defined, then go back to see if Redmine fits.

---

Other recommendations based on experience:

• Keep in mind that the most common incidents are either (Bugs (some call them defects) and Enhancements (some call them features))
• Make a process for defect and another process for features (Each process needs different treatment)
• Get commitment from your team
• Get commitment from your customers (internal only)
• Have a process to handle exceptions, this will be more useful than what you think

Answer 3

Ask yourself what you want from your bug tracking system and what connections it needs to have with other systems (traceability, searchability)?

Are the following points relevant to you (by no means an exhaustive list)?

• Track bugs for the lifetime of the project (develop and forget)
• Track bugs for the lifetime of the product (long term support)
• Do you just track bugs so that you correct them?
• Do you track bugs to also find out how to improve your processes (will cost more but should bring longer term benefits)?
• Do you need to track time spent on investigation and resolution (to analyse costs, I'm sure there are other ways to do this)?
• A good practice is to reference the bug number in the version control comments for the solution.
• A good practice is to link bug reports to a relevant test cases and/or relevant sections of the design document that they pertain to (and to associated business requirements) - this allows you to review the history of bugs whenever you are going to change those requirements or design elements (such traceability allows better risk analysis and test requirements planning of future changes).
• Write up a non-regression test case as part of the resolution of this bug.

Answer 4

As someone who has tested and created software (as well as lead a team), here are some of the items that mean the most to me when it comes to defect best practices

• Process, first and foremost... - Figure out the defect management/testing methodology right now. This will get rid of many headaches down the road for you and everyone involved (for instance, you aren't letting your developers close defects, are you? Who will be in charge of verifying fixed defects?) Look at several test methodologies and tailor one to your needs. Define the roles and responsibilities for everyone involved in the software quality process. Figure out the life-cycle of your bugs as well. Most of the major tools (Bugzilla, Jira, etc) have a defect life-cycle already baked in. Some of the better ones will let you define the life-cycle so that it fits your needs.
• ...now give it the critical once over - Everyone gets the process they deserve, but not always the one they wanted. Review everything you came up with in the previous step, and make sure you have something that works and addresses all your testing needs. Fix any issues, make sure it works now, and keep an eye on everything moving forward in case something needs to be adjusted.
• Clearly describe the defect when it is found! - This might not be on the process level, but it is one of my pet peeves. Make sure that defects are being described clearly so that you will be able to understand what they are now and in the future when someone needs to review them. It is really disturbing to come back to a 6-12+ month old bug and not be able to make heads nor tails of what the issue was.
• Track your defects - This will tell you a great deal about the health of your software. Linking defects to specific test cases, and more specifically to functional areas, will help you determine where efforts should be focused. If 70% of your defects are coming from the XYZ functionality, does it mean that the quality of the code in this area of the application needs to be re-examined?

Answer 5

+1 to Geo re focusing on processes.

You may want to do searches for testing methodologies, quality assurance in software development and variations on those.

Answer 6

Lots of great recommendations in this thread. The mere fact that you're migrating to bug tracking (versus using email and whiteboards) will be a great step forward in your quality management process.

The one thing that seems to be missing from the answers so far is software version information. If you're doing multi-stream development or supporting n releases back from the current release, it will be very helpful for you to have "Found in" and "Fixed in" fields so you can track this sort of thing.