Hello Testers,
Defect Life Cycle or Bug Life Cycle is an important concept in Software testing and both manual and automation tester must be aware about it. It is also frequently asked interview question. So let’s learn about this.
A life cycle is a series of stages through which something passes during its lifetime i.e. from beginning to an end. When a defect is found, it must be fixed and removed from application. A defect passes through different stages before it is closed. We will see about those stages here.
An important point I want to share here that Defect life cycle can be completely customized by an organisation. An organisation can add, remove, break down , rename stages of life cycle. But it will be less or more will be around actual stages of life cycle. So you must have an idea of basic stages of defect life cycle.
A typical defect life cycle will be as below:
- When a defect is found, it is logged in a defect tracking tool. Generally tool itself assigned status as “NEW” to this defect. Kindly note here that “New” status of defect is not a confirmation if it is really a defect. If you see in some MNCs, you will find that at initial stage, a defect is categorized as an Incident. Because at this stage we are not sure if it is really a defect.
- When a defect is logged, it is assigned to a Developer or Developer Manager or BA. Then defect is moved to “ASSIGNED” status. It is done to intimate intended people about defect.
- In some organisation, BA can review the defect and can confirm if it is a valid defect and then BA assigned it to development team. If a defect is assigned directly to development team, they check and confirm if it is a valid bug. At this stage, defect is moved to “OPEN” stage. “Open” stage indicates some type of work is going on defect.
- A defect might be duplicate of previously raised bug. In this case development team/ BA can mark defect as “DUPLICATE”. Marking status as “Duplicate” of a defect is actually an end of its life cycle. Some organisation may asks defect reporter to mark defect as Closed. Some organisation keep it as it is to get the count of duplicate bug reported by testing team.
- When Development team tries to reproduce and finds it is as per requirement, they can mark defect as “REJECTED”.
- When Development team unable to reproduce defect, they can mark defect as “Not Reproducible”.
- It is also possible that defect was occurred because of faulty data or proper setup of data. For example: A user is not an admin user but we expect for some admin functionalities in user. In this case defect can be marked as “Data Issue”.
- If raised defect is not needed to fix soon or requirements are not clear or requirements are re-designed or restructuring is needed etc, can be marked as “DEFERRED”. This defect could be fix later.
- If defect is valid and require fix, development team will fix it and move defect to “FIXED” status and assigned to code reviewer.
- Code reviewer reviews the code and if everything goes correct, new code is deployed in QA server and mark it as “READY TO RETEST”.
- Now testing team will retest the defect and mark it “RETESTED” and “CLOSED”. If it is not working as expected, it will be marked as “REOPENED” and will be assigned to intended people.
- A defect with status “Close” can be reopened at later stage, if it occurs in future because of some code changes.
I explained a typical defect life cycle above You may notice changes/addition/removal in process.
If you have any doubt, feel free to comment below. If you like my posts, please like, comment, share and subscribe. #ThanksForReading
#HappySelenium