Bug Report Life Cycle

The life cycle of the bug report begins when a bug is discovered and logged by a tester and ends when it is closed after exhaustive verification. Software life cycle is directly related to the bug detected during testing. A bug is assigned different statuses throughout its entire life cycle.

The bug life cycle involves the following stages and can be in one of the states:

• New: When a bug is encountered for the first time, it is in a new state by default
• Assigned: Once the bug has been logged by the tester, the senior management confirms the presence of the defect and makes the developer, a member of the development team, have the responsibility for it. Its state is made as Assigned.
• Open: The developer commits to the bug, is investigating it and attempting to resolve the problem.
• Fixed: After the developer has modified the code and fixed the bug, its state is marked as Fixed, and it can be sent to the software development quality assurance team for re-looking and re-testing.
• Pending Retest: The bug is returned to the testing team to be retested and its status will remains as Pending Retest.
• Retest: The testers verify the changes made by the developers and re-test them.
• Verified: The bug has been tested with the latest software build and after making sure that the product is working appropriately the tester confirms the bug as fixed. Then the tester moves the bug to “Verified” status.
• Reopen: In case if the bug still exists after the fix made by the developer, its state is changed to “Reopen”, and the bug goes through the same stage of the life cycle.
• Closed: As soon as the developer repairs the bug, the product is sent to the testers for re-testing. If the tester is about to close the bug after retesting it or finding it as duplicate he changes the bug’s status to “Closed.” Now the bug is fixed and logged as a bug.
• Duplicate: In case if the bug is reporting a behavior that already described by an open bug or a similar bug has been raised before, then one bug’s status is marked as “Duplicate”.
• Rejected: When the developer thinks that it is not a bug, he rejects it. Then the bug’s state is altered to “Rejected”.
• Deferred: The bug is sure to be fixed, but only in another bug life cycle, and then it can be moved to future release. The reason is the low priority bug and time issue.
• Not a bug: The bug can be in such a state, for instance, if the client asks to make insignificant changes to the product: change the font, color, etc.