Defect/Bug Life Cycle in Software Testing

Introduction to Defect/Bug Life Cycle

Hey, have you ever encountered a problem or an abnormality with an application or software that you use in day-to-day life?

If yes, then it can prove to be a disaster in your productivity or even application security! This particular problem in software is what is known as a Bug or a Defect.

Sometimes, bugs can prove to be very disastrous! In 1991, 28 American soldiers lost their lives when a software bug in the MIM-104 missile system caused its system clock to drift by 1/3rd of a second due to which it failed to intercept the incoming Iraqi missile resulting in such a great loss of life!

Every software development company wants that their software remains free from any kind of defect so as to meet the customer’s demands with the utmost quality.

In major software companies, these bugs are eliminated right before the release of the software so that the companies deliver a quality product to their customers.

This is achieved by following the Defect Life Cycle. During the software development phase, a large number of defects may arise which could be resolved by following the Defect Life Cycle!

What is Defect/Bug Life Cycle?

The Defect Life Cycle is also known as Bug Life Cycle. It is a process in which bug goes through different stages in its entire life.

Consider the bug as a lively object that has different states throughout its life right from the state it’s opened by the tester to the state of getting closed after getting fixed.

There are two major people during any Software development process:

1. Software Developer: The one who designs and implements the code.

2. Software Tester: The one whose role is to find as many bugs as possible in the software and to open that bug for fixing it in the Defect Life Cycle.

A bug may arise in software, due to some mistake made by the Software developer either during the design or development of the product. It’s the tester’s or QA’s paramount responsibility to find all the bugs in software during the development phase itself so that they are fixed before the release of the software.

Defect/Bug Life Cycle Workflow

The following flowchart diagram shows the Defect Life Cycle Workflow:

Each rectangle in the diagram represents a particular state of the bug in its life cycle.

This Defect Life Cycle workflow is tentative and may change from team to team and from project to project. Some companies may use tools like Jira & some may use other tools like Backlog for following the bug life cycle.

Let’s take a look at each of the state in this workflow and what does it mean in the realm of Defect Life Cycle :

1. New: This is the first state of a bug in the defect life cycle. In this stage, the tester finds a defect. Tester makes a complete specification document of what the bug is, how to reproduce it and what are the tests for which it fails. The tester then assigns the bug as a “New” bug.

   Let us say, a software company is making a website for some client and has got a bug in it.

The tester tests the screen layout of the website in various screen sizes and finds out that for 5.5-inch screen size, the rendering is not according to the needs. The tester creates a bug report for the bug & that bug is in the new state.

2. Assign: In this state, the bug in the “New” state is assigned to a particular developer or a team by the project lead manager or some person of responsibility.

   In the case of our bug, the screen size issue is assigned to the front-end development team.

3. Open: This is the state where the software developer starts analyzing the bug on the basis of the report developed by the tester in Step-1. The software developer starts working on fixing the code and reimplements the portions of the code that were causing trouble. There could also be a situation at this state when the developer feels like the bug is not appropriate, in that case, it is transferred to one of the following states in the defect life cycle i.e. Duplicate, Rejected, Deferred. These states would be discussed later in the blog.

   In case of our bug, the front-end team analyses the reason for the bug, propose a solution for fixing it and apply the fixed patch to the codebase.

4. Fixed: This is the state when the developer fixes the “Open” bug after all the testing and validation from his/her side.

   In case of our bug, the front-end team fixes and tests/validates whether the issue is resolved or not.

5. Pending Retest: This is the state assigned to the bug, between the time the developer fixes the problem to the time the tester starts retesting whether the problem has been rectified or not.

   In case of our bug, the front-end team marks the bug as “pending-retest”.

6. Retest: This is the state of the bug when the actual retesting of the problem is started by the software tester.

The tester tests whether the problem has been fixed or not based on the requirements that were mentioned in the bug report of Step-1. Software tester also tests whether the current fix doesn’t affect any existing functionality in the software which in turn would lead to the origin of new bugs.

In the case of our bug, the tester tests whether the bug is properly fixed or not. He also checks whether any new bug has originated in the patched code.

7. Reopen: The state of a bug is changed to reopen if the tester during the retesting process finds that the bug is not completely resolved or some new bug has originated and should be again assigned to a developer for further fixation.

In case of our bug, if the tester after performing all the tests, finds that there is some component that is still not fixed, the tester reopens the bug and the bug again goes to the “Open” stage with an updated bug report.

8. Verified: If the tester during the Retest state finds that all the issues are resolved, then the tester assigns the verified state to the bug in the defect life cycle.

In the case of our bug, if the tester becomes satisfied after performing all the tests, the tester changes the state of the bug as verified.

9. Closed: The tester changes the state of the bug to closed, once the bug no longer exists.

   In case of our bug, the mobile screen rendering bug is marked as closed at this stage.

Some miscellaneous states that may exist after the “Open” state in the defect bug cycle are as follows:

1. Rejected: If the developer feels that the bug report created by the tester is not correct or is not genuine, the developer puts the bug in the “Rejected” state.

2. Duplicate: If the developer feels that the bug is a copy of some other “Open” bug, or if there is some other bug that may fix this incoming bug as well, then the developer may assign the bug to the “Duplicate” state.

3. Deferred: This state may take place when the software developer finds that the bug at the current time is not important for fixing or fixing the bug may be costly, or fixing the bug is not possible at the current time, the software developer may put the bug in the “Deferred” state so that it could be fixed in the future release of the software.

4. Not a Bug: When the developer finds that the bug has very little significance in the correct functioning of the software, the developer may assign the “Not a Bug” state to the bug in the defect life cycle.