.ico)
Defect Life Cycle/Bug Life Cycle
Introduction
In this tutorial we see What is Defect Life Cycle in Software Testing and the actual how status is change and actual workflow of Defect Life Cycle also we see detail explanation of defect life cycle and different status and there meaning.
We also give you a recent ask question and there answer to interview prospective.
It is very important to understand the status and there work or meaning in Defect Life Cycle also defect life cycle is the part of STLC.
What is Defect Life Cycle/Bug Life Cycle
Defect life cycle is a journey of defect from open to fix in short it is the journey of defect though his lifetime.Defect life cycle in which there is a specific set of status shows defect or bug goes through in its entire life.
The purpose of Defect life cycle is to easily understand and communicate current status of defect. which helps to understand the defect status.
Following are the status are used in defect life cycle/Bug life cycle
Defect Status/Bug Status are used in defect life cycle which shows present position of defect from which the defect or a bug is currently undergoing.
The main goal of defect status is to properly shows the current position and progress of a defect or bug in order to going into better track and understand the actual progress of the defect life cycle.
The defect life cycle involves the following resources.
Tester – To find the bug and re-test the solved bug.
Project Lead/ Project Manager/ Test Lead – To verify the bug and assign it to the
respective developer.
Developer – To resolve the bug or defect filed by the tester.
Following are the Defect status flow
How actual status are changes in Defect Life Cycle/Bug Life Cycle/Defect workflow
1.Whenever tester raise a defect by default status the status is new.
2.Then Newly created defect is assigns to the development team to work on the defect so here sometime developer project manager analyses the bug its company to company decide.
3.After analyses the defect if the defect is valid then developer accept that defect and start working on that defect that time developer change its status from new to open or in progress.
4.In some case if developer is not acknowledge the defect that time tester also change the status from new to open.
5.After accepting the defect developer start fix the defect when developer fix the defect he change status from open to fix.
6.When defect is fix by developer he send modified build to the tester.
7.After receive the modified build tester start retesting on that modified build.
8.After that there could be 2 possibilities.
1)Defect is reoccurs.
2)Defect is fix.
9.If defect is reoccurs then tester change his status from fix to reopened.
10.Then tester again assign this defect to developer then again developer change its status from reopened to open.
11.In some cases developer will reject defect there could be various reasons
1)Misunderstanding the requirement.
2)Duplicate defect.
3) Environmental issue.
4)Need more information.
12.Misunderstanding is requirement developer not understanding or clear the requirement then also he reject the defect.
13.If the developer see the defect as same as any other defect OR
If the concept of the defect matches any other defect also another tester is also raise same defect then the status of the defect is changed to Duplicate by the developer.
14.There is some environmental issue means there is a hardware, software, network configuration issue then also he reject the defect.
15.By covering all the above issue defect is valid and still developer is reject the defect then tester need to convince him with the proof.
Tester should show him a proof of screen shots of requirement, also test cases which is review by developer himself.
Still developer not accepting the defect in that case tester should inform to lead and discuss this point in scrum meeting.
16.In some case developer makes the status open to deferred.
If defect is valid, but developer don't have sufficient time to fix that defect in the recent sprint and in some cases need more information about defect that time with the permission of client developer will change the status open to deferred.
17.This can happen when defect is found on last day of sprint and tester don't have time to regression testing this type of defect will inform to client also.
18.In case of critical deferred defect new change in request is not acceptable.
19.If the defect does not have an impact on the functionality of the application then the status of the defect gets changed to “Not a Bug”.
Advantages of Defect Life Cycle/Bug life Cycle.
1.Delivering a high-quality product/software that is free of defects or bugs.
2.maintaining better communication along with satisfactory teamwork by the team and Project Manager.
4.It helps to detecting the issues and understanding what Defect are in trends.
5.Reaching the goal of better customer satisfaction.
Disadvantages of Defect Life Cycle/Bug life Cycle.
1.It takes a more time.
2.Different variations of the Bug Life Cycle need to be followed.
3.No control over the testing environment leads to a bad impact on the software.
Important Questions Related To Interview/Exam
1) What are the reasons developer reject your defects?
→In some cases developer will reject defect there could be various reasons
1)Misunderstanding the requirement.
2)Duplicate defect.
3) Environmental issue.
4)Need more information.
2)How we can avoid duplicate defect?
3)If the defect is valid developer is reject the defect so as tester what we do?
→By covering all the issue defect is valid and still developer is reject the defect then tester need to convince him with the proof.
Tester should show him a proof of screen shots of requirement, also test cases which is review by developer himself.
Still developer not accepting the defect in that case tester should inform to lead and discuss this point in scrum meeting.
4)What is the status of a defect when it is initially found?
→When a new defect is found, then by default status is new this is the first state of a newly found defect.
5)What is a reproducible defect?
→A defect that is found/detect repeatedly and it is been captured in every execution, then such type of defect is called a “reproducible ” defect.
6)When developer change status as deferred and why?
→If defect is valid, but developer don't have sufficient time to fix that defect in the recent sprint. And in some cases need more information about defect that time with the permission of client developer will change the status open to deferred.
.ico){kind=small}