BugTracking

Introduction

This page describes a bug tracking process we use in the project.

Definitions

From Wikipedia, the free encyclopedia:

A bug tracking system is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work. It may be regarded as a type of issue tracking system.

Many bug tracking systems, such as those used by most open source software projects, allow users to enter bug reports directly. Other systems are used only internally in a company or organization doing software development.

Requirements

Taken from the beautiful article 'How to Report Bugs Effectively' by Simon Tatham (highly recommended to read):

• The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
• In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
• When your computer does something unexpected, freeze. Do nothing until you're calm, and don't do anything that you think might be dangerous.
• By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
• Be ready to provide extra information if the programmer needs it. If they didn't need it, they wouldn't be asking for it. They aren't being deliberately awkward. Have version numbers at your fingertips, because they will probably be needed.
• Write clearly. Say what you mean, and make sure it can't be misinterpreted.
• Above all, be precise. Programmers like precision.

Bug lifecycle

Every record in the tracker has several fields and the maintaining them is a bug Owner responsibility.

The most important is Status field.

Typical bug life

1. When an issue is created, it is New
2. When an owner has detected that he has a new bug and he is OK with it it is Accepted (and if not - he has to either move the issue to correct owner or mark it as Invalid)
3. When the actual work is in progress it is Started
4. When the changes are committed to HEAD (not branch) it should be Fixed or Verified (Verified is better - it means that you have also made tests that check the correctness of your implementation)
5. After that the bug dissapears from list of active issues and we consider it as Closed.

All the statuses are actually self-descriptive.