Question from the title keeps popping up now and again. It has been like that ever since we launched Active Collab back in October 2007.
I always found it strange because we used Active Collab for bug tracking from day one (actually, from day -90 because we started using it to manage Active Collab development three months before we made it available for sale).
That’s 6+ years, during which we grew from 3 guys in a rented apartment to 12 developers in A51 office. Amount of work that we push through Active Collab also grew significantly in that period and it scaled nicely. Our bug tracking process
From our perspective, bug is a task that needs to be handled. We have a main project for Active Collab maintenance (called “Active Collab Maintenance”).
In that project we have following task categories:
- Bug Reports — reported defects,
- Enhancements — smaller changes that are not big enough to justify a separate project,
- Refactoring — it’s important to pay off your technical debt.
Here is a simple chart that shows how bugs flow through our system:
When bug gets reported (by our support technicians), it starts with a label NEW. Our QA has a filter that shows him all tasks marked as NEW. He goes through them and checks if he can reproduce the problem. Once reproduced, bug becomes CONFIRMED and we decide when this bug will be fixed (usually next bug fix release). For example, if bug was reported for Active Collab 5.0.13 today and it was confirmed, our QA would set it’s milestone to “Active Collab 5.0.x Maintenance” (thus making it clear that it needs to be fixed in one of 5.0.x bug fix releases) and set it’s label to CONFIRMED.
Then our developers and project managers come in play. They see a list of confirmed bugs and pick the ones they want to work on by assigning themselves to the task. When they start working, they set task’s label to INPROGRESS.
Once they fix the problem, they mark the task as FINISHED. QA sees a FINISHED task and creates a new test build to verify that bug has actually been fixed.
If it has been fixed, task label is set to VERIFIED and task is completed. In (rare) cases when bug was not fully covered and needs more work, our QA marks it as REOPENED and notifies the developer about the problem.
REOPENED task gets FINISHED again, and process continues until we get to VERIFIED.
That’s the basic process. We also have a couple of extra labels to cover the edge cases (bug not reproducible, blocks etc):
- WORKS4ME — bug can’t be reproduced,
- BLOCKED — bug that can’t be fixed because it is blocked by another task,
- BLOCKER — bug that is blocking other tasks.
From our experience, you can do wonders with a set of simple tools and clear communication between team members
Cause even the most sophisticated, specialized bug tracking tool will fail without the latter.
