If your involved in software development you need a bug tracker, there i said it. The reason for this post is to try to talk a little about the benefits of a good big tracking system, not the obvious ones but some benefits that you may not have thought of.
1. They help you to put process into your bug fixing
By using status for the bug as it moves thru the fix process you can make sure that it passes through all the different gates before it gets released. Examples of different status that i use in my process are:
1. New = Ticket created but not yet looked at
2. Hard Shoulder = Tickets that cannot be moved due to something blocking development
3. Elaboration Doing = Ticket is in the process of being correctly spec’ed and time required estimated
4. Elaboration Done = Ticket has been spec’ed and time required estimated
5. Development Doing = Development work has started on the ticket
6. Development Done = Development work has been completed on the ticket
7. Peer Code Review Doing = New code is peer reviewed to check for errors (Static analysis and code should be run)
8. Peer Code Review Done = Review has been completed and any errors fixed
9. QA Doing = Functionality of new development tested by QA on beta
10. QA Done = Planned testing of new development functionality completed
11. UAT Doing = (UAT = User Acceptance Testing) End business users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications. This is done on beta
12. UAT Done = UAT complete
13. Ready to deploy = Developer has prepared the new code to be deployed into the live environment
14. Done Live = Dev Op’s has deployed the new code to the live environment
15. Closed = All parties happy with new live functionality so ticket can be closed
This might seem like a rather long list but i have found there is definite value in each of these status and when followed the team has reassurance that any problems should be found before the functionality goes live.
2. They become a knowledge base
The first thing i do when a new bug is raised is do a search in the bug tracker for similar bugs, this provides to different things:
1. It tells me if the bug has already been raised
2. Its tells me if similar bugs have been raised. If this is the case i can look back on the issues recored in that bug and they may well help the developer diagnose the problem in the new similar bug. Also because i am logging what testing i did to check the bug fix i can often use a variation of this to carry out the fix test on the new similar bug, this can be a real time saver.
3. They help you identify troublesome areas of an application
Most bug trackers have reporting functionality, this used in conjunction with some custom bug status that are used to indicate areas of the application where the bug was found can help to identify weak points in the application. This information can then be used to work out areas that seem fragile where it would be useful to have a good set of regression tests to pick up problems early. Also it could help to flag up code areas where a refactor of the code should be done to make that area more robust.
4. Identify the dev’s who’s code has the most bugs..
Possibly a bit divisive this one but rather than use it as a stick to beat the dev with it should be used to help the dev get some extra training or mentoring to help them to improve there code.
5. See which dev is overloaded
Which dev has the most bugs assigned to them?, should some of the bugs assigned to them be spread round to other dev’s in the team?
Thats a few added benefits of bug tracking systems that you maybe haven’t thought about. I am sure there are more, if you have any examples please put some in the comments.