Software Testing - Bug Life Cycle

In Software Testing, the Bug life Cycle or a Defect life cycle describes the states of a defect. With respect to situations, the state of defect also changes.

What is a Defect?

A defect (also known as bug) is an inaccuracy in the application that is introduced while a software has been developed. This results in the software not working as expected. In other words, a defect causes the deviation from the actual to expected behavior of the software.

It is not possible to develop software without a defect. So it is the primary responsibility of the testers to detect as many defects (prominently in the early phases of software development) as possible so that the software is delivered with quality. However, bugs can be detected by both developers and testers.

Thus detecting defects in a software is essential to maintain the quality. The return on investment on a defect is high. A defect creates effective communication and coordination between the testers and developers who work towards fixing the defect.

What is a Bug Life Cycle?

Defect life cycle, also known as Bug Life cycle is the journey of a defect through its lifetime. It starts right from the introduction of a new defect till its closure. The path and stages of the defect life cycle followed in different organizations or teams differ from one another. This is because of the absence of a uniform testing process everywhere.

Following a defect life cycle is essentially beneficial for both the developers and the testers. The primary purpose of having a defect life cycle is to develop a clear communication and coordination among teams to have a quicker fix to the defects.

What is a Defect Status?

The defect status denotes the present condition of the defect and its advancement. Thus a defect status helps to keep a check on the path of the defect and examines its progress in the defect life cycle.

The defect statuses are listed below −

New

A potential defect that is raised and yet to be validated has the new status. This is the first state of the defect life cycle. Once a testing team begins its task, it identifies all the possible areas in the software where there is a deviation between the actual and the expected results. All these discrepancies are logged as new defects in the software.

Assigned

Once a new defect is assigned to a development team to be addressed, its status is known as assigned. The defect is still not resolved at this point. Once it is in the new state, it is triaged in a meeting. Post discussion, if it is proved to be a valid one, it remains assigned to a developer for a fix.

Open

Once a defect is under investigation by a developer and he starts working on fixing the error in the code, at this point the defect status is open. If the developer comes to the conclusion that the raised defect is incorrect or will not be fixed now, he either defers or rejects the defect.

Fixed

The developer fixes the code and makes the necessary changes to remove the error in the software, the defect status is changed to the fixed state. It also indicates that the code changes will be ready for testing from the upcoming build.

Test

Once the defect is fixed it becomes ready for testing and it comes to the test team’s bucket to verify if it still exists or is fixed. The status of the defect is now moved to test.

Verified

Once a defect is retested and it has been verified by a tester, it is now in verified status. Post retesting it, if the tester confirms that it no longer exists, and a right fix is provided by the developer, the defect status is changed to verified.

Retest

Once the defect comes to retest state, the tester reverifies it to confirm if it still exists or not.

Closed

This is the final state of the defect when it is closed by the tester after he verifies that it no longer exists in the software.

Reopened

Once a defect comes for retest to a tester and he finds it is not yet fixed, he changes its status to reopened. Then it again moves to the open state for the developers to fix it.

Deferred

When a defect will not be addressed in the current cycle, it is deferred to future release. If the defect identified is not on priority to be fixed, or there may be a requirement change from the customer and can be resolved in future releases or sprints, the status of the defect is changed to deferred.

Rejected

A defect can be rejected for any of the three reasons, namely Duplicate, NOT a Defect, Non Reproducible. A defect can also be rejected by a developer because of improper communication or understanding from the tester.

Cannot Be Fixed

Once a defect is logged and the developers finds that the fix requires additional technology support, skills, and cost, at that time the status of the defect is changed to cannot be fixed.

Duplicate

If it is seen that a defect is raised more than once, its status is changed to the duplicate. Ultimately, a duplicate defect moves to the rejected status.

Not a Defect

If a defect logged is not impacting any requirements or functionalities of the software, it is moved to a not a defect status.

Not Reproducible

If a defect is not replicated again for some reasons, the developer changes its status of that defect to not reproducible state.

Need More Information

If a defect is not replicated again by the developer at that time then he changes the state of that defect to a need for more information status. At that stage, it is the task of the tester to provide all the necessary information about the defect to the developer.

Defect Life Cycle Workflow

The defect life cycle workflow is represented in the below diagram −

The steps involved in the defect or bug life cycle are listed below −

Step 1 − A member of the test team logs a defect which will have the status as New.

Step 2 − The defect is triaged and assigned to a developer for further analysis.

Step 3 − The developer goes through the defect and starts working on it. The defect status moves to the Open.

Step 4 − If the defect is found to impact none of the functionalities or requirements (Not a defect), or it is of less priority for a fix as of now and will be taken up in future release (Deferred), or a Duplicate one, the status of the defect is changed to Rejected.

Step 5 − If the Step 4 is not valid, the developer resolves the defect, the code changes reflect from the next build. The status of the defect is moved to Fixed at this point.

Step 6 − The tester retests the defect and validates if it's resolved. If the defect no longer exists, its status is changed to Closed, else its status is moved to the Reopened state and it is again assigned back to the developer.

Conclusion

This concludes our comprehensive take on the tutorial on Software Testing Bug Life Cycle. We’ve started with describing what is a defect or a bug, what is a defect or a bug life cycle, what is a defect or a bug status, and a defect or bug workflow. This equips you with in-depth knowledge of the Bug Life Cycle in Software Testing. It is wise to keep practicing what you’ve learned and exploring others relevant to Software Testing to deepen your understanding and expand your horizons.