Defect Life Cycle

Defect life cycle is also known as BUG LIFE CYCLE. It is a journey of a defect/bug from its identification to its closure.

While executing the testing phase, every defect has to be reported in a defect log also known as incident report. The test manager has to define a process for defects identification to disposal of the defect. This process consists of following steps:

•          Recognition of a defect

•          Investigation as to why the defect occurred

•          Defect removal

The life-cycle may vary from organization to organization and is usually governed by the software testing process of the organization or projects depending on factors like company policy, software developmental model (e.g., Agile, Waterfall, etc.), and project timeline. However, the actual extensive defect life-cycle is illustrated below:

The purpose of the Defect life cycle is to easily coordinate bug status changes to various assignee's and make the bug fixing process systematic.

Status Explanation

• NEW: When a tester finds a new defect, it is logged and posted for the first time. This defect is yet  to be studied/approved, so it is assigned a status as “New”.

• ASSIGNED: Once the bug is posted by the tester, Test Lead/ Development Lead/ Project Lead studies the "New" defect and if it is found to be valid, it is assigned to a member of the Development Team and the status has been changed to "Assigned".

• OPEN: Now the assigned developer starts analysing and works on the defect. Now it is assigned developer's responsibility to fix the defect and update it to "Fixed". Sometimes, "Assigned" and "Open" can be same status. In that case, a defect can be open yet unassigned.

• FIXED: When a developer makes a necessary code change and verifies the change, the defect's state is set to "Fixed".

• PENDING RE-TEST: Once the defect is fixed the developer gives a particular code for re-testing to the tester. Since the software testing remains pending from the testers end, the status assigned is "Pending re-test". This happens because the bug fix might have caused other bugs to appear, or the bug may not have been fixed properly.

• RE-TEST: At this stage, testing team does the re-testing of the code to check whether the defect is fixed by the developer or not and changes the status to "Re-test".

• VERIFIED: The tester “re-tests” the bug after it got “fixed” by the developer. If the bug has been successfully eliminated by the developers and there is no bug detected in the software, the testing team sets its status to “Verified”.

• RE-OPEN: If the bug still exists even after the developer has fixed the bug, its state is set back to Re-Open and the life-cycle restarts.

• CLOSED: Once the bug has been verified as fixed and the bug is no longer exists, the testing team closes the issue and set the status as “Closed”. This is the happy ending.

• DUPLICATE: If the defect is repeated twice or defect corresponds to the same concept as the bug, the status is changed to "Duplicate".

• REJECTED: If the developer team feels that the defect is not a genuine defect then they will change the defect’s state to “Rejected”.

• DIFFERED: If the defect is not of a prime priority and it is expected to get fixed in the next release, then status "Deferred" is assigned to such bugs.

• NOT A BUG: Defects that were misclassified as defects and it does not affect the functionality of the application then the status assigned to a bug is "Not a bug".

Defect Life Cycle Explained:

• Tester finds the defect

• Status assigned to defect- “New”

• A defect is forwarded to Project Manager for analyse

• Project Manager decides whether a defect is valid or not

• Here the defect is not valid- a status is given "Rejected"

• So, project manager assigns a status rejected. If the defect is not rejected, then the next step is to check whether it is in scope. Suppose we have another function- email functionality for the same application, and you find a problem with that. But it is not a part of the current release then such defects are assigned as a postponed or deferred status

• Next, the manager verifies whether a similar defect was raised earlier. If yes defect is assigned a status “duplicate”

• If no the defect is assigned to the developer who starts fixing the code. During this stage, the defect is assigned a status in- progress

• Once the code is fixed. A defect is assigned a status “fixed”

• Next, the tester will re-test the code. In case, the Test Case passes the defect is closed. If the test cases fail again, the defect is re-opened and assigned to the developer

Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax order that was fixed and assigned a status closed. During the second upgrade release the same defect again re-surfaced. In such cases, a closed defect will be re-opened

That's all to Bug Life Cycle

 

Guidelines:

• Make sure the entire team understands what each defect status exactly means. Also, make sure the defect life cycle is well documented. 

• Ensure that each individual clearly understands his/her responsibility as regards to each defect. Ensure that enough detail is entered in each status change. For example, do not simply DROP a defect but provide a reason for doing so. 

• If a defect tracking tool is being used, avoid entertaining any ‘defect related requests’ without an appropriate change in the status of the defect in the tool. Do not let anybody take shortcuts. Or else, you will never be able to get up-to-date and reliable defect metrics for analysis.