What Is Bug Life Cycle In Software Testing

Table of Contents

What is Bug Life Cycle in Software Testing?

1. Bug Life Cycle (BLC) is the time span between the bug being found and it is being closed.

2. Bug Life Cycle (BLC) is also called Defect Management Life Cycle.

3. We have some different statuses of bugs like new/open, assigned, fix, re-open, and closed.

4. As soon as the test engineer finds the bug, the status is given as New, which indicates that a bug is just found.

5. This new bug needs to be reported to the concerned Developer by changing the status to Assigned so that the responsible person should take care of the bug.

6. Below figure shows the different stages of the bug life cycle:

7. Then the Developer first goes through the bug, which means that the Developers read all the navigation steps to decide whether it is a valid bug or not.

8. Based on this, if the bug is valid, the Developer starts reproducing the bug on the application, once the bug is successfully reproduced, the Developer will analyze the code and does the necessary changes, and change the status to Fixed.

9. Once the code changes are done, and the bug is fixed, the test engineer re-tests the bug, which means that the test engineer performs the same action once again, which is mentioned in the bug report, and changes the status accordingly:

10. Close, if the bug fixes properly, and functionally works according to the requirement.

11. Re-open, if the bug still exists or not working properly as per the requirement, then the bug sends it back to the Developer once again.

12. This process is going on continuously until all the bugs are fixed and closed.

13. Bug life cycle in Jira or defect life cycle in Jira is the same as above.

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:

1. Invalid/rejected

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:

This defect should be resolved after all the serious bugs are fixed.

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:

1. 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.)

2. High Priority & Low Severity: The spelling mistakes that happen on the cover page or heading or title of an application.

3. 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.

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).

What is Bug Life Cycle in Software Testing