The Defect Life Cycle (also commonly referred to as the Bug Life Cycle in industry), is the term used to describe a software defect from identification to correction. We will highlight the life cycle used by Bugzilla.org here; however, many organizations, companies, and open source project teams will make adaptations to the life cycle to best suit their respective organization. The defect life cycle will also be guided by the specific type or types of software testing that the project team employs as well as the manner that software defects are tracked. If you are learning about the Bug Life Cycle in a college course, ensure you cite the specific steps in the course text or you could find yourself losing points on an exam!
What Are the Steps of the Defect Life Cycle?
Step 1 – A new defect or bug is created or opened.
Step 2 – A developer fixes the defect.
Step 3 – A quality assurance or QA representative checks the defect to verify it has been fixed. If not, then it fails verification and goes back to development for action. If the defect does pass QA, then it is verified closed.
Step 4 – If the reported defect is assessed as not being a bug, it is closed after validation by QA.
Step 5 – If the defect comes back or resurfaces after being closed, then its status changes to re-opened.
The Defect Life Cycle Expanded
When the defect life cycle is applied in industry, all bugs are not necessarily closed out as fixed. They may be postponed, deferred, or rejected depending on how the project team has setup the project team to handle defects. Common statuses assigned to defects once they are identified are: New, Postpone, Retest, Open, Pending Reject, Pending Retest, Closed, and Deferred. The following are some examples of paths that defects may take during the bug life cycle:
Step 1 – A software tester discovers a defect and reports to the Test Team Lead via a defect tracking system.
Step 2 – The Test Team Lead or designated QA representative assess the validity of the defect.
Step 3 – QA determines the defect is not valid and the defect status is changed to “Rejected.”
Rejected Defect Expanded
Step 1 – A new defect is passed to the QA or Test Team leader.
Step 2 – QA verifies the defect is valid and changes the status to “New.” The bug is then reported to the development team.
Step 3 – The project development team leader and designated personnel assess the validity of the bug. The bug is determined to be invalid and status changed to “Pending Reject” and goes back to the testing team.
Step 4 – The test team leader reads the feedback from the development team and agrees that the bug is invalid. The status is then changed to “Rejected.”
Defect from Discovery to Closed Status
Step 1 – A new defect or bug is discovered and reported to QA or the Test Team Lead.
Step 2 – QA determines that the bug is valid and marks the status as “New.” The defect is then reported to the development team.
Step 3 – The development team determines that the bug is valid. The team leader assigns the defect to a team member. Status of the defect changes to “Assigned.”
Step 4 – The development team member fixes the bug. Status is changed to “Fixed” and is passed back to the team leader.
Step 5 – The development team leader changes the bug status to “Pending Retest” and sends to the testing team.
Step 6 – The test team leader changes the defect status to “Retest” and sends to a tester.
Step 7 – The tester validates the defect is fixed and changes the status to “Closed.” If the tester finds that the same problem remains, he or she will consult with the test team leader and change the bug status to “Reopen.” The defect will then be passed to the development team to fix.
A Rejected Bug Example
Step 1 – A new bug is reported to the Test Team Lead (or QA).
Step 2 – QA validates the bug and changes the status to “New.”
Step 3 – The development team attempts to validate the bug but is unable to replicate the conditions that resulted in the defect being discovered.
Step 4 – The test team is unable to recreate the situation that resulted in the original bug report and status is changed to “Rejected.”
Postponing Defect Fixes
If testing a defect requires on functionality or data that is not available, the defect correction and retesting is postponed. When this occurs, the status is changed to “Postponed.” If the defect is not considered critical and can be postponed indefinitely, then the project team may change the status to “Deferred.”
Defect Life Cycle Final Status Entries
In the expanded example, all defects will have a final status of either Postponed, Deferred, Closed, or Rejected.
What is Bugzilla?
The Bugzilla project is a Defect Tracking System that allows software development teams to track project bugs. Bugzilla is produced as an open source project and has become one of the most popular bug tracking software suites throughout industry since the application has been in production. The primary features of Bugzilla include the ability to track bugs and code changes, submit and review software patches, enable communication between project team members, and manage a projects QA efforts. Ultimately the Bugzilla toolkit helps teams get organized and effectively communicate between each other.
Bugzilla’s Defect Life Cycle
Bugzilla’s defect life cycle used to be hard coded into their software application. This is no longer the case with the most recent release of the application as the team leader now has the ability to add or remove steps or requirements in the Bugzilla Life Cycle. The following is the baseline defect life cycle for Bugzilla at the time of this writing: