Defect Life Cycle

Before jump into defect life cycle i want to share an incident with you.

Few days back when I tried to call from my Samsung slide mobile phone, I observed that the display suddenly turned into multi color and I am not able to view anything clear on the screen. I approached the service center and informed the issue. The technician verified my mobile and said that this is because of the strip inside the phone which was broken.  They informed me that the strip will be replaced and will be delivered by next day morning.  Next day I went to the store and collected my phone by paying the bill. I have verified whether I am able see the screen properly and I made a call to my friend to confirm it is working. This is a common situation to all of us with mobiles or other accessories.  Right?

The same life cycle is applicable to software defects also.

           The client emails or logs the problem they are facing. The SQA team will verify whether it is the expected behavior of the system or is it really a problem. If team identifies it as a problem they try to reproduce it. Once the defect is reproduced they will intimate the client the root cause of the problem and the estimated time to deliver the fix. After taking approval from the client the fix will be made ready and will be tested internally and delivers to the client within scheduled time.  Client will test the defect and they are satisfied with the solution provided then they will close the defect.

The above mentioned scenario is a simple happy flow.

Let us discuss more detailed about defect life cycle.

Let us start with the defect identified by the tester in testing phase.

Tester identifies a mismatch between expected and actual results and logs a defect by providing required information in the bug tracking tool or in spreadsheet. Now the defect status is “New”.  All the new defects will be discussed in triage meeting where the managers and the leads verifies whether the defects are valid or not or requires more information on the defect. 

In Triage if they think more information required then they assigns that defect to the tester who raised it with defect status as “More Information required” or “Insufficient Information”.  Tester provides the requested information and assigns back with defect status “New”. This defect will again comes for discussion in next triage meeting and if it is considered as invalid then that would be assigned to tester with status “Not a Defect” or “User error”. If tester wants to discuss on the defect then he participates in next triage otherwise he closes the defect.

If the defect is considered as valid defect then the next question will be is this defect reproducible? If it is inconsistent then that will be assigned for thorough analysis.  If bug is reproducible then comes next question is this defect worth of a fix? i.e., how much it impacts the business of the client. If the impact is low then it will be deferred to next releases or bug can be closed. If the impact is high then that will planned for the immediate releases and assigns to the developer to provide fix with defect status as “Assigned”

Developer fixes that defect and unit tests that defect and assigns to the Lead/manager/tester with defect status as “Fixed”. Once the build is released to SQA and defect was assigned to concern tester, Tester retests that defect and if found that the problem is properly addressed then closes the defect at the same time he tests the impacted areas so that no regression defects were introduced. If tester identifies that the problem still exist then assigns the defect to the developer with status “Not Fixed”