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

How about Not A Bug? On Fri, 04 Aug 2000, Zak Greant wrote: > 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. > > > > > -- > PHP Quality Assurance Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-qa-unsubscribe@lists.php.net > For additional commands, e-mail: php-qa-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > -Andrei The Heineken Uncertainty Principle: You can never be sure how many beers you had last night.