Defect Life Cycle (Bug Life Cycle) in Software Testing

In the earlier posts, we have seen life cycles such as STLC and ATLC. In this post, We’ll go over all you need to know about the Bug Life Cycle (Defect Life Cycle).

What is Defect Life Cycle?

Defect Life Cycle is also known as Bug Life Cycle. Bug Life Cycle or Defect Life Cycle in testing is the particular arrangement of states that defect or bug goes through in all its years. The reason behind the Defect life cycle is to easily arrange and convey the current status of bugs, which changes to different chosen ones and make the imperfection fixing actions organized and proficient.

What is Bug or Defect??

A bug or Defect can be categorized as unusual behavior of a product or software. It begins when the defect is encountered and finishes when a defect is closed, after verifying it isn’t duplicated.

Stages Of Bug or Defect Life Cycle

Following are the different stages of the bug life cycle (defect life cycle):

New:

At the point when the tester tracks down another defect. He ought to give an appropriate Defect record to the Development group to duplicate and fix the imperfection. In this express, the situation with the imperfection posted by the tester is “New”.

Assigned:

The defect that is in the situation with New will be supported (if legitimate) and allocated to the development group by the Test Lead/Project manager. When the defect is allocated then the situation with the bug changes to “Assigned”.

Open:

The development group begins to examine and deals with the bug fix.

Fixed:

At the point when a developer makes the essential code change and checks the change, at that point, the situation with the bug will be changed as “Fixed” and the bug is passed to the testing group.

Test:

In the event that the status is “Test”, it implies the imperfection is fixed and prepared to do the test if it is fixed.

Verified:

The tester re-tests the bug after it is sorted out by the developer. In the event that there is no bug identified in the product, the bug is fixed and the status allocated is “checked.”

Closed:

After confirmed the fix, assuming the bug is does not exist anymore, the situation with the bug will be allocated as “Shut.”

Reopen:

On the off chance if the bug stays as before after the retest, the tester posts the imperfection utilizing the imperfection retesting report and changes the status to “Reopen”. Again the bug went to the existence cycle to be fixed.

Duplicate:

In the event that the bug is replicated twice or the deformity compares to a similar idea of the bug, the status is changed to “Duplicate” by the development group.

Deferred:

Below are the cases when the manager deferred the bug which is as follow:

• When the bug is found during the finish of the delivery and it is minor or not essential to fix it right away.
• When the bug isn’t connected with the current build.
• When the bug is supposed to sort in the next release.
• The client is thinking to change the prerequisite.
• In such an event the status will be changed as “Deferred” and fixed in the following delivery.

Rejected:

In the event that the framework is working as per details and the bug is only because of some confusion, (for example, related to old necessities or additional highlights) then, at that point the Team lead or designers can stamp such bugs as “Rejected”.

Cannot be fixed:

Innovation not supported, the root of the item issue, Cost of fixing a bug is more or not affordable.

Need more information:

When a developer can’t reproduce the bug according to the actions given by a tester then the developer can change the status to “Need more information”. The tester needs to add complete replicating steps and allot bugs back to the improvement group for a fix for this situation. This will not occur if the tester writes a correct defect document.