At Gioorgi.com we will start a series of articles about bug tracking. As usual, our posts will be short, tight focused and open to comments and improvement.
A software will be full of bugs at some point of its life, and every good developer/project manager must be ready to address these issue. Let’s see how to fix them….
A bug tracking software is used by end-user to properly inform development team about bugs.
It can be used also for internal house keepking, too.
The bug tracking software keeps the bugs organized, and give to the end users the ability to track bug resolutions, without “annoying” developers with emails, calls and so on.
Developer need only to fix bugs, and mark them “resolved” on the bug tracker.
The Project Manager will close it, after checking it is working (release of bug fix is not immediate…it can take some times based on release schedules).
The end user will be informed via email when a bug is closed (this it’s done via a “monitoring” feature).
For every bug ethere is a lifecycle, based on a simpleworkflow:
- Bug borns
- Bug is ackowledged and scheduled for resolution
- Bug is ifixed
- The bugfix is tested by a quality assourance team (this annoying task is done by a project manager sometimes)
- The bug is closed, and the documentation is left on line.
Sometimes bug are not true bugs, but features (at Gioorgi.com they are our preferred defects :)
Other times bugs are replica of just solved bugs or are not well explained.
In such situations, the developer explain the misunderstanding and go on.
An end user should always provide a way to reproduce the bug: if the bug cannot be reproduced, the developer will not be able to fix it; it is still useful to signal it, anyway.
Last but not least, bug tracking software can be a very important piece of your business, and what you read inside it is official and sometimes reserved.
So keep a polite language, be serious and avoid jokes, because the end user opening the bug is already irritated by the bug itself…