Bug/Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced. Defect life cycle is related to the bug found during testing.
The Defect Management Process should be followed during the overall software development process and not only for specific testing or development activities. If a defect found in the testing phase then a question can be raised that if the defect is caught in this phase then what about the other defects that are alive in the system which may cause system failure if it occurs and is not yet discovered. So all processes like review process, static testing, inspection, etc., need to strengthen and everyone in the project should be serious about the process and contribute wherever necessary.
Defect management process is explained below in detail.
Defect Prevention is the best method to eliminate the defects in the early stage of testing instead of finding the defects in the later stage and then fixing it. This method is also cost effective as the cost required for fixing the defects found in the early stages of testing is very low.
However, it is not possible to remove all the defects but at least you can minimize the impact of the defect and cost to fix the same.
The major steps involved in Defect Prevention are as follow:
When a deliverable (system, product or document) reaches its pre-defined milestone then you can say a deliverable is a baseline. In this process, the product or the deliverable moves from one stage to another and as the deliverable moves from one stage to another, the existing defects in the system also gets carried forward to the next milestone or stage.
For Example, consider a scenario of coding, unit testing and then system testing. If a developer performs coding and unit testing, then system testing is carried out by the testing team. Here coding and Unit Testing is one milestone and System Testing is another milestone. So, during unit testing, if the developer finds some issues then it is not called as a defect as these issues are identified before the meeting of the milestone deadline. Once the coding and unit testing have been completed, the developer hand-overs the code for system testing and then you can say that the code is “baselined” and ready for next milestone, here, in this case, it is “system testing”.
Now, if the issues are identified during testing then it is called as the defect as it is identified after the completion of the earlier milestone i.e. coding and unit testing.
Basically, the deliverables are baselined when the changes in the deliverables are finalized and all possible defects are identified and fixed. Then the same deliverable passes on to the next group who will work on it.
It is almost impossible to remove all the defects from the system and make a system as a defect-free one. But you can identify the defects early before they become costlier to the project. We can say that the defect discovered means it is formally brought to the attention of the development team and after analysis of that the defect development team also accepted it as a defect.
Steps involved in Defect Discovery are as follows:
In the above process, the testing team has identified the defect and reported to the development team. Now here the development team needs to proceed for the resolution of the defect.
The steps involved in the defect resolution are as follows:
Though in the defect resolution process the defects are prioritized and fixed, from a process perspective, it does not mean that lower priority defects are not important and are not impacting much to the system. From process improvement point of view, all defects identified are same as a critical defect.
Even these minor defects can improve the process and prevent the occurrences of any defect which may impact system failure in the future. Identification of a defect having a lower impact on the system may not be a big deal but the occurrences of such defect in the system itself is a big deal.
For process improvement, everyone in the project needs to check from where the defect was originated. Based on that you can make changes in the validation process, base-lining document, review process which may catch the defects early in the process which are less expensive.
The defect life cycle can vary from organization to organization and from project to project based on several factors like organization policy, software development model used (like Agile, Iterative), project timelines, team structure etc.
This is important to know about the various states of a defect for understanding the life cycle of a defect. The main intention of performing a testing activity is to check if the product has any issues/errors. In terms of real scenarios, errors/mistakes/faults are all referred to as bugs/defects and hence we can say, that the main objective of doing a testing is to assure that the product is less prone to defects (no defects is an unrealistic situation).
Some organizations / projects / managers may adopt a simpler life cycle while others may use a more extensive life cycle as described below. Simpler implementations of the bug life cycle may not include all the states that have been shown below. This may not provide as much clarity into the defect / defect metrics, when the defects are being analyzed at a later date.
A Defect, in simple terms, is a flaw or an error in an application that is restricting the normal flow of an application by mismatching the expected behavior of an application with the actual one. The defect occurs when any mistake is made by a developer during the designing or building of an application and when this flaw is found by a tester, it is termed as a defect.
It is the responsibility of a tester to do a thorough testing of an application with an intention to find as many defects as possible to ensure that a quality product will reach the customer. It is important to understand about defect life cycle before moving to the workflow and different states of the defect.
A defect can be introduced in any phase of SLDC (Software Development Life Cycle) so it is very important that test team is involved from beginning of SDLC for detecting and removal of defects. The earliest the defect is detected and rectified, the minimal cost of quality will incur.
For Example: If the defect is identified in requirements phase then the cost of fixing it is just modifying the requirement whereas if the wrong requirement is designed and implemented in the code and found during the test execution phase then the cost to fix that defect will be very high as the fix needs to be done in requirement and then those changes need to propagate to design, development and testing again.
Hence, let’s take know more about Defect Life Cycle and understand the workflow of a defect and the different states of a defect.
A Defect life cycle, also known as a Bug life cycle, is a cycle of a defect from which it goes through covering the different states in its entire life. This starts as soon as any new defect is found by a tester and comes to an end when a tester closes that defect assuring that it won’t get reproduced again.
It is now time to understand the actual workflow of a defect life cycle with the help of a simple diagram as shown below.
1) New: This is the first state of a defect in the defect life cycle. When any new defect is found, it falls in a ‘New’ state and validations and testing are performed on this defect in the later stages of the defect life cycle.
2) Assigned: In this stage, a newly created defect is assigned to the development team for working on the defect. This is assigned by the project lead or the manager of the testing team to a developer.
3) Open: Here, the developer starts the process of analyzing the defect and works on fixing it, if required. If the developer feels that the defect is not appropriate then it may get transferred to any of the below four states namely Duplicate, Deferred, Rejected or Not a Bug-based upon the specific reason.
4) Fixed: When the developer finishes the task of fixing a defect by making the required changes then he can mark the status of the defect as ‘Fixed’.
5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester for retesting the defect at their end and till the tester works on retesting the defect, the state of the defect remains in ‘Pending Retest’.
6) Retest: At this point, the tester starts the task of working on the retesting of the defect to verify if the defect is fixed accurately by the developer as per the requirements or not.
7) Reopen: If any issue still persists in the defect then it will be assigned to the developer again for testing and the status of the defect gets changed to ‘Reopen’.
8) Verified: If the tester does not find any issue in the defect after being assigned to the developer for retesting and he feels that if the defect has been fixed accurately then the status of the defect gets assigned to ‘Verified’.
9) Closed: When the defect does not exist any longer then the tester changes the status of the defect to ‘Closed’.
On successful logging, the bug is reviewed by Development or Test manager. Test manager can set the bug status as Open, can Assign the bug to developer or bug may be deferred until next release.
There are some important guidelines which can be adopted before starting to work with defect life cycle.
This is all about Defect Life Cycle. A Defect Life Cycle or Bug life cycle is a cycle which a defect goes through during its life span. Using the defect life cycle, the testers can identify a defect at any stage. While experimentally testing a case, you can seek a hidden defect. The defect life cycle plays a crucial role in bringing out defects from an operation.
Prev.
