Work on the Bug Reporting System (00/08/04)

Hello All, My work on the bug reporting system has lead me to believe that a more comprehensive understanding of the lifecycle of a bug is needed. I am sure that any good CS manual on debugging has a similar overview, however I have worked these up from scratch to try and better my own understanding. So, if you find some holes in my logic, don't be too surprised. Please let me know what you think - we should be able to construct a useful set of states for a bug report from this. This work was originally done in the Leo editor - an outlining/literate programming tool. If anyone else is using Leo and would like my original file, then let me know. If you want to grab a copy of leo, go to http://sourceforge.net/project/?group_id=3458 Zak The Life Cycle of a Bug ------------------------ Reported * The process begins when a user submits a bug report Reviewed * Someone reviews the bug Poorly Described * If the bug report does not contain enough information, then contact the user for more information. If the user does not provide more feedback in x days then end the bug life cycle here. Well Described * If the bug report contains enough information to be evaluated, then proceed to the next step. Invalid * If the bug is due to user error or misinterpretation, then end the bug life cycle here. Valid * If the bug is not due to user error - like misconfiguration, syntax errors in scripts, etc... then proceed to the next step. Not Unique * If the bug appears to be a duplicate of an existing bug, then end the bug life cycle here. Unique * If the bug does not match any know bug, then consider it to be unique and continue. Not Reproduceable * If the bug cannot be reproduced in a current release, end the bug life cycle here. Note the full details of platform and version tested with. Intermittent * If the bug cannot be reliably reproduced, then either: - the set of conditions that cause the bug have not been completely or properly identified - or the bug has been misinterpreted. Re-evaluate proposed causes for the bug and search for alternate causes. Reproduceable * If the bug can be reliably reproduced, then proceed to the next stage. Not Analyzable * If no cause can be determined, then other developers should be contacted. * If no cause can be determined after rigorous analysis, then the bug cycle should end here. Analyzable * By this stage, the bug has been proven to be valid. * The bug should now be analyzed to determine its cause. Not Fixable * After analysis, the bug may prove to be unfixable. If this is the case, then close end the life cycle here. Not Assignable * Certain bugs cannot be fixed by the team. In cases like this, the bug life cycle should end here. Suspended * Certain situations may require that the bug be suspended - either pending future developments, available developer time, etc... Assigned * Now that the root cause of the bug has been determined, a developer should be assigned to correct the error. Not Fixable * Humpty Dumpty bug - the bug could not be fixed, not by all the kings horse's and all the king's men... Fixed * Someone fixes the bug :) Regression Test * Once the fix is in place, a regression test should be in place to catch re-occurences of the bug in the future.