What is Defect Life Cycle in Software Testing?
- Defect Life Cycle (DLC) is the time span between the bug being found and it is being closed.
- A defect Life Cycle (DLC) is also called Defect Management Life Cycle.
- We have some different statuses of defects like new/open, assigned, fix, re-open, and closed.
- As soon as the test engineer finds the defect, the status is given as New, which indicates that a defect is just found.
- This new defect needs to be reported to the concerned Developer by changing the status to Assigned so that the responsible person should take care of the defect.
- Below figure shows the different stages of the defect life cycle:
- Then the Developer first goes through the defect, which means that the Developers read all the navigation steps to decide whether it is a valid defect or not.
- Based on this, if the defect is valid, the Developer starts reproducing the defect on the application, once the defect is successfully reproduced, the Developer will analyze the code and does the necessary changes, and change the status to Fixed.
- Once the code changes are done, and the defect is fixed, the test engineer re-tests the defect, which means that the test engineer performs the same action once again, which is mentioned in the defect report, and changes the status accordingly:
- Close, if the defect fixes properly, and functionally works according to the requirement.
- Re-open, if the defect still exists or not working properly as per the requirement, then the defect sends it back to the Developer once again.
- This process is going on continuously until all the defects is fixed and closed.
- defect life cycle in Jira or bug life cycle in Jira is the same as above.
Who to Assign the Defect
The defect can be assigned to the following:
- Developers lead
- Test lead
Different statuses of the defect life cycle in software testing:
- Can’t fix
- Not reproducible
- RFE (Request for Enhancement)
- New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.
- Assigned: Once the defect is posted by the tester, the lead of the tester approves the defect and assigns the defect to the developer team.
- Open: The developer starts analyzing and works on the defect fix
- Fixed: When a developer makes a necessary code change and verifies the change, he or she can make the defect status “Fixed.”
- Pending retest: Once the defect is fixed the developer gives a particular code for retesting the code to the tester. Since the software testing remains pending from the tester’s end, the status assigned is “pending retest.”
- Retest: The tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and changes the status to “Re-test.”
- Verified: The tester re-tests the defect after it got fixed by the developer. If there is no defect detected in the software, then the defect is fixed and the status assigned is “verified.”
- Reopen: If the defect persists even after the developer has fixed the defect, the tester changes the status to “reopened”. Once again the defect goes through the life cycle.
- Closed: If the defect no longer exists then the tester assigns the status “Closed.”
- Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the defect, the status is changed to “duplicate.”
- Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to “rejected.”
- Deferred: If the present defect is not of a priority and if it is expected to get fixed in the next release, then the status is “Deferred”
- Not a bug: If it does not affect the functionality of the application then the status assigned to a defect is “Not a bug”.
SAMPLE DEFECT REPORT IN DEFECT LIFE CYCLE (BLC)
Sample template as the example shown below:
Defect Name: The application crash on clicking the SAVE button while creating a new user.
Defect ID: (It will be automatically created by the Defect Tracking tool once you save this defect)
Area Path: USERS menu > New Users
Build Number: Version Number 5.0.1
Severity: HIGH (High/Medium/Low) or 1
Priority: HIGH (High/Medium/Low) or 1
Assigned to: Developer-X
Reported By: Your Name
Reported On: Date
Status: New/Open/Active/To Do
Application crash on clicking the SAVE button while creating a new
the user, hence unable to create a new user in the application.
Severity and Priority With Examples
There are two key things in defects of the software testing. They are:
What is the difference between Severity and Priority?
- Severity in testing is the impact of a bug in an application.
- Found bug introducing how much impact on feature/requirement of an application.
- A highly impacted bug means its severity is high.
- For example: If an application is not able to log in then its impact on an application is very high so the severity would be high.
Severity can be of the following types:
- This has to be fixed immediately within 24 hours.
- This generally occurs in cases when an entire functionality is blocked and no testing can proceed as a result of this.
- Any defect that needs immediate attention and impacts the testing process will be classified under the immediate category
- All the Critical/high-severity defects fall under this category
- This defect should be resolved after all the serious bugs are fixed.
- A defect with low priority indicates that there is definitely an issue, but it doesn’t have to be fixed asap
- The defect that does not result in any serious damage to the system and the desired results can be easily obtained by working around the defects then the severity is stated as minor.
- Priority defines the order in which we should resolve a defect.
- Should we fix it now, or can it wait?
- This priority status is set by the tester to the developer mentioning the time frame to fix the defect.
- If high priority is mentioned then the developer has to fix it as the earliest. The priority status is set based on the customer’s requirements.
- For example: If the company name is misspelled on the home page of the website, then the priority is high and severity is low to fix it.
Priority can be of the following types:
- Low Priority: The defect is an irritant that should be repaired, but a repair can be deferred until after more serious defects have been fixed.
- Medium Priority: The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.
- High Priority: The defect must be resolved as soon as possible because the defect is affecting the application or the product severely. The system cannot be used until the repair has been done.
A few very important scenarios related to the severity and priority are asked during the interview:
- High Priority & High Severity: An error that occurs on the basic functionality of the application and will not allow the user to use the system. (Eg. A site maintaining the student details, on saving record if it, doesn’t allow to save the record then this is a high priority and high severity bug.)
- High Priority & Low Severity: The spelling mistakes that happen on the cover page or heading or title of an application.
- High Severity & Low Priority: An error that occurs on the functionality of the application (for which there is no workaround) and will not allow the user to use the system but on click of the link which is rarely used by the end user.
- Low Priority and Low Severity: Any cosmetic or spelling issues which are within a paragraph or in the report (Not on the cover page, heading, or title).