What is Bug Life Cycle in Software Testing? [Defect]

During the development of software, testers carry out different types of testing to identify and fix bugs or defects in the software product to ensure it meets quality standards. Due to the presence of bugs or defects in a software product, testers do not get the expected results as specified in the requirements.

But what exactly are these bugs or defects? A bug or defect is a fault, error, or mistake in a software product that forces it to produce unexpected and incorrect results or behave unintendedly. It causes the software product to behave in such a way that it is not intended to do. Moreover, a bug or defect affects the normal or expected flow of the software product.

A defect or bug may occur in a software product when a developer makes a mistake in writing its source code. Testers are responsible for identifying bugs, and they report these bugs to developers in order to get them fixed. The process of identifying and correcting bugs is called debugging .

There is a specific life cycle of a bug or defect in software testing. This article intends to make you aware of the life cycle of a bug or defect, along with the different states involved in the bug life cycle.

So, let us get started!

What is a Bug Life Cycle?

Bug life cycle, also known as defect life cycle, is the set of states that a bug or defect undergoes throughout its life cycle. In general, the life cycle of a bug starts when a software tester detects it and ends when the tester closes the defect or bug, assuring that it won’t reappear later.

The life cycle of a bug or defect varies from organization to organization and project to project. This is because of different development platforms, testing tools , and testing methodologies. Moreover, the number of states a bug or defect goes through depends on the testing process and testing tool.

Defect Status

In software testing, the term ‘defect status’ is used to describe the current state that a bug goes through. The primary goal of defect status is to represent the status or progress of a bug or defect.

States in Bug Life Cycle

The following are the different states involved in the bug or defect life cycle:

New: It is the first state of the bug life cycle. Whenever a tester identifies a bug, it falls in the ‘New’ state or is assigned the status ‘New’.
Assigned: When the bug is in the ‘New’ state, the test lead approves and assigns it to the development team to get fixed and resolved. When the test lead assigns any new bug to the development team, its status changes to ‘Assigned’.
Open: A bug enters into the ‘Open’ state when the development team starts working on it to fix it. If the development team approves the bug assigned to them, they start working on it. However, if they reject the bug in case it is not appropriate, it either goes to the ‘Rejected’ or ‘Deferred’ state.
Fixed: After the development team works on the bug and fixes it, the status of that bug changes to ‘Fixed’.
Pending Retest: Once the development team fixes the bug or defect, it sends the modified code to the testing team for the retest. When the retesting of that code remains pending from the end of the testing team, the bug's status changes to ‘Pending Retest’.
Retest: In this state, the testing team retests the code to verify whether the bug or defect is fixed or not. After testing, they change the status of the bug to ‘Retest’.
Verified: When the testing team finds that the defect is fixed after retesting and it won’t be reproduced, they change the status of the bug to ‘Verified’.
Closed: It is the final state of the bug life cycle. Once the testing team verifies that the bug is fixed and won’t reproduce, they mark it as ‘Closed’.

Some other States

Apart from the above states, a software bug can also undergo the following states:

Reopen: If, after testing, the testing team finds that the bug is not fixed, they change the status of the bug to ‘Reopen’. From here, the bug goes to the ‘Open’ state and follows the bug life cycle to get fixed.

Rejected: When the development team feels that the bug assigned by the testing team is not genuine, they mark it as ‘Rejected’. There are three different causes for the rejection of the bug, namely Duplicate Defect, Not a Defect, Non-Reproducible.
Deferred: If the development team feels that the bug or defect is not of high or prime priority and can be fixed in later releases, they mark it as ‘Deferred’.
Duplicate : There may be a case where a defect may be the same as some other defect or is repeated twice. In such cases, it is marked as ‘Duplicate’.
Not a Defect: When the identified bug has no effect on the software product, its status changes to ‘Not a Defect’.
Can’t be Fixed: If the development team cannot fix the bug due to technical support, lack of the required skills, the cost for fixing the bug, or any other reasons, they mark it as ‘Can’t be Fixed’.

Bug Life Cycle [Explained]

Here is the complete explanation of the bug life cycle:

A tester identifies a bug in the software product while performing testing on it and assigns the status ‘New’.
After identifying the bugs and assigning them the ‘New’ status, the test lead analyzes and approves them.
Further, the testing team assigns the approved bugs to the development team for fixing and changes the status to ‘Assigned’.
When the development team starts working on the bugs, they change the status to ‘open’. There are various states that the bug may enter, depending upon its nature.
- If the development team finds that the specific bug is not genuine, they mark it as ‘Rejected’.
- If they find the same bug twice or analogous to other bugs, they mark it ‘Duplicate’.
- The bug is marked as ‘Deferred’ if the development team feels that the current bug is not of high priority and can be fixed later.
- If the development team feels that the bug cannot be fixed, they mark it as ‘Can’t be Fixed’.
After that, the development team works on modifying the code and fixing the bug. Once the bug is fixed, the development team changes the status of the bug to ‘Fixed’.
Later, the testing team retests the code to find whether the bug is fixed or not and marks the status as ‘Retest'. If they find that the bug is not fixed or the code behaves the same as previously, they mark it as ‘Reopen.' And that bug once again goes to the ‘Open’ state.
If the testing team finds the bug is fixed and will not reproduce later, they change its status to ‘Verified’. Finally, the testing team marks the status of the bug as ‘Closed’.

Conclusion

A bug or defect causes the software product to behave unexpectedly or produce wrong and unwanted results. When the testing team identifies the bug in the software product, it goes through various states, as discussed above. Also, a bug moves from one state to another throughout its lifecycle.

We hope that you have gained enough clarity on the bug life cycle through this article. If you have any doubts or queries, feel free to share them in the comments section below.

Frequently Asked Questions

1. What happens if a tester still finds that the bug is not fixed after the development team fixes it?

If the testing team finds that the bug is not resolved even after the development team fixes it, they mark it as ‘Reopen’. The bug then goes to the ‘Open’ state and again moves through the different states of the bug life cycle to get fixed.

2. What is a defect report?

A defect report is a detailed document containing the list of identified defects, along with their descriptions. It helps developers clearly understand the problem and find a relevant solution. Moreover, a defect report consists of the following information:

Defect ID
Description of the Defect
Build Version in which the defect was detected
Reproducible Defect or not
Status of the Defect
Severity of the Defect
Priority of the Defect
Tester Name
Date of the Testing
Developer Name to whom it is assigned to get fixed.
The environment in which the defect is found.

3. When does the bug move into the ‘Deferred’ state?

When the development team receives bugs from the testing team and assesses that a particular bug is not of prime priority and can be fixed in later versions of the software product. Such a bug is marked as ‘Deferred’.

4. What is bug leakage?

A bug leakage takes place when a bug is detected, that should have been detected in the earlier versions or builds of an application. Also, we can say that a bug leakage takes place when the end-users identify defects during the user-acceptance testing. These end-users are the small group of real users that test the software product. After testing, they provide feedback before making it public.

5. What is bug release?

When the bugs are identified after the release of the software product, it is referred to as a bug release.

People are also reading:

What is Bug Life Cycle in Software Testing? (Defect)