Product

philippines.jpg

small irc button

 
Home > Developers > QA & Testing > Lifecycle of a Bug in the Issue Tracker
Document Actions

Lifecycle of a Bug in the Issue Tracker

  1. A defect is opened with status NEW and should be assigned a sub-component (ie "Loan Accounts", "Bulk Entry", "Configuration", etc).  Based on the sub-component chosen, the issue tracker will automatically assign the bug to the appropriate person.  There is no need to assign a new defect.  In general, new bugs will be automatically assigned to "MifosTriage" for review.

  2. The sub-component owner (or the Mifos Triage team) will evaluate the item, make comments, and re-assign the item, if appropriate.

  3. Once the item is assigned to someone., it is likely that the comments in the defect will indicate what to do next.
    4. Examples:
    • Estimate the amount of work and assign back to sub-component owner for review
    • Complete the work item or defect, change the status to "FIXED", update the comments and other fields, and assign to the person who opened the defect for verification.
    • Assign the defect back to someone (Sub-component owner or the Reporter) to get more information
    • In some cases, for example if it is decided the defect is WONTFIX, the Assignee should change the status to Closed (or challenge Triage in the comments!)

  4. If you are working on the defect, change the status from NEW to STARTED and make sure the issue is assigned to your username.

  5. Once you have completed work on the bug, change the status to RESOLVED/FIXED and put the SVN revision number containing the fix and any relevant configuration settings/changes necessary for the tester to verify the bug in the comments.  If you are submitting a patch with the fix, please mark the bug as resolved after your patch has been reviewed and committed into SVN.

  6. Once a bug is fixed and marked as RESOLVED/FIXED, it should be re-assigned back to QA or to the person who opened the bug (Reporter).  This is done by changing the value of the "QA contact" field to the appropriate individual.  The default value for this field is "MifosQA", which will ensure the QA team verifies the bug. 

  7. When you are ready to verify a bug, make sure to change the QA contact field to your username to indicate that you are working on verifying the issue.

  8. If the bug is verified, QA or the reporter should change the status to VERIFIED. If the item has been verified in production, change the status to CLOSED. The Person Who Opens a Bug (Reporter) Should Be the Person Who Verifies and Closes the Bug. As a general rule, a bug should be assigned back to the person who opened the bug or to a tester. The person who fixes a bug should not be the person who Verfies and Closes a bug. Do not close another person's bug unless you have an understanding with that person.

  9. If the defect reproduces or work item is incomplete, assign the item back to the person who was responsible for the work with details of why it is not Verified/Closed.
last modified 2008-04-08 12:31
Grameen logo