What is Bug Life Cycle in Software Testing?
3. We have some different statuses of bugs like new/open, assigned, fix, re-open, and closed.
Who to assign the bug
The bug can be assigned to the following:
- Developers
- Developers lead
- Test lead
Following are the different statuses of the bug life cycle in software testing:
2. Duplicate
3. Postpone/deferred
4. Can’t fix
5. Not reproducible
6. RFE (Request for Enhancement)
7. New: When a new bug is logged and posted for the first time. It is assigned a status as NEW.
8. Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to the developer team.
9. Open: The developer starts analyzing and works on the bug fix
10. Fixed: When a developer makes a necessary code change and verifies the change, he or she can make the bug status “Fixed.”
11. Pending retest: Once the bug 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.”
12. Retest: The tester does the retesting of the code at this stage to check whether the bug is fixed by the developer or not and changes the status to “Re-test.”
13. Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified.”
14. Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
15. Closed: If the bug no longer exists then the tester assigns the status “Closed.”
16. Duplicate: If the bug is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate.”
17. Rejected: If the developer feels the bug is not a genuine defect then it changes the defect to “rejected.”
18. Deferred: If the present bug is not of a priority and if it is expected to get fixed in the next release, then the status is “Deferred”
19. Not a bug: If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.
SAMPLE BUG REPORT IN BUG LIFE CYCLE (BLC)
Sample template as the example shown below:
- Bug Name: The application crash on clicking the SAVE button while creating a new user.
- Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug)
- 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
- Reason: Defect
- Status: New/Open/Active/To Do
- Environment/Server: Dev/Stage/Production
- Description:
- 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:
- Severity
- Priority
What is the difference between Severity and Priority?
1) Severity:
· 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:
High Severity:
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
Medium Severity:
Low Severity:
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.
2) Priority:
· 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 at 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:
4. 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).