A bug life cycle in software testing is a set of statuses designed to coordinate defect management. A bug status helps keep all the members of the development team posted on the progress. The cycle starts when a QA engineer reports a new issue found in the tested software and finishes when this issue is sold.
Stages of Bug Life Cycle in Testing
A defect life cycle can consist of different stages depending on a company’s practices. Available defect management tools, number of team members, and adopted methodologies are among the things that can impact the workflow and, thus, a variety of bug life cycle stages.
Below, you will find information about the frequently used statuses that designate different stages of the defect management process. Some of them are mandatory and some are optional, used to provide more details about the progress.
New
Let’s say a software tester starts inspecting a product and finds a bug. What’s next? A specialist logs the defect into a tracking system, describing the steps for reproducing, environment details (OS, device, browser), and severity. The defect is assigned the New status.
Assigned
A project manager, team lead, or developer in charge reviews the report. They check whether the bug is valid. If yes, they choose a developer to fix the defect. The choice might depend on the type of the bug (e.g., front-end or back-end, coded in PHP or Python, etc.) and available resources (who has enough time and expertise to solve the problem). The bug goes to the Assigned status.
Opened
A developer who is to fix the issue sets the Opened status and starts analyzing the problem. A closer look at the defect may reveal some pitfalls. Thus, instead of fixing the bug, a developer has to change the status to one of the following:
- Duplicate — the identical problem was already reported.
- Rejected — the bug is not reproducible; a developer can’t understand the problem due to the ambiguous wording; there are no clear requirements; a QA engineer misunderstood the requirements; improper environment configuration during testing, etc.
- Deferred — the issue is not urgent and can be fixed later.
- Not a bug — the problem does not affect software functionality (e.g., a suggestion to change a font or background color).
- Cannot be fixed — for some reason, this bug has to become a feature, as there is no way to fix it (for now or at all).
- Need more info — a developer needs extra information about the defect to find its root cause.
If the problem is reproducible and obvious, the developer starts working on fixing it.
Fixed
As soon as the developer makes changes to the code, the bug goes to Fixed.
Retest
The task returns to the QA specialist, who checks if the problem is actually solved.
Reopened
If a software tester discovers that it is still possible to reproduce the bug, they Reopen it. A developer looks into the problems once more. The task goes from Fixed to Retest to Reopened until the defect no longer exists.
Verified
If a QA specialist confirms that the bug has been fixed, the status changes to Verified.
Closed
Closed is a status that marks the final stage of the bug life cycle. The work is done.
Participants of a Bug Life Cycle
There are two main participants in the bug life cycle — a software tester and a developer. One finds and logs the bug, and the other fixes it. In bigger teams, however, other specialists get involved in the defect management process.
When it comes to defining bug severity and priority, also known as bug triage, someone has to evaluate and prioritize the defects. The person in charge of prioritization discusses the particularities of defects with other team members. All the people involved in this process are known as the defect triage committee. The process can go like this:
- A Test Lead or QA Engineer determines bug severity.
- A Development Team Lead assesses the potential risks.
- A Project Manager decides on bug priority and discusses the deadlines for fixing.
- A Development Team Lead assigns the task to a developer and sets deadlines.
Again, the exact workflow depends on the team structure and processes. In big companies, Department Heads and CTO can be involved in the discussion, too.
The Example of a Bug Life Cycle
New. A QA engineer (let’s call him Bob) goes to the website of an online bookstore he is testing and adds a book to a cart. The item appears in the cart, but Bob can’t order two of the same books. A click on “+” to change the number of items doesn’t actually change it. Bob describes the problem and logs a bug as New.
Assigned. A PM (let’s suppose this is Susie, and she’s in charge of delegating the tasks) sees a bug on the list. The problem appears to be valid and serious. Susie assigns the task to a back-end developer, Alex, who coded the cart functionality.
Open. Alex sees a new task and tries to reproduce it following the instructions in the report. Indeed, the “+” doesn’t work as intended. Alex changes the bug status to Open and starts looking for the root cause.
Sometimes, however, things don’t go this way. Alex knows that bug can be invalid. In this case, instead of marking the defect as Open and trying to fix it straight away, he can use a different status, for example:
- Duplicate. When studying the report, Alex realizes that Sam, another software tester, logged this bug yesterday. Alex marks the bug as Duplicate. There is no need to add it to the pull of tasks once more — it is already there.
- Rejected. Using the instructions from the bug report, Alex adds the book to the cart and clicks on “+.” The number of items changes to two. How’s that possible? Maybe an unstable internet connection caused the problem. Or maybe, the defect appears on a specific device, but Bob forgot to include this information in the description.
- Deferred. The bug occurs only on the Firefox browser, which has a small share among users. Alex decides to fix it later, after figuring out a more critical problem: why the payments fail.
- skills of the test team members.
- Not a bug. Alex is concerned at first, but then he realizes that Bob tried to buy an extra ebook. It’s impossible because of the website logic: a user can access an ebook from any device, there’s no need to buy it twice.
- Need more info. Alex does not understand under what circumstances the bug appears. Is a user logged in or not? Is Bob trying to add an item on a product page or at the stage of order confirmation?
- Cannot be fixed. Alex is aware of this problem and has tried to solve it more than once. It is a hard-to-find bug, and he needs to review a huge codebase to fix it. At the moment, a user can order two books by typing the number “2” into the box displaying the number of items. It’ll do for now.
Fixed. Alex finds a mistake in the code and fixes it. The status goes to Fixed.
Retest. Bob receives a notification about the status change. He needs to check the functionality once more and make sure users can change the number of books now. He sets the Retest status and starts working.
Reopened. Unfortunately, during the retesting, Bob discovers that the bug still occurs. A click on “+” does not change the number of items. The task goes back to Alex under Reopened status. Alex needs to look into the problem once more. The bug will go through the Fixed and Retest stages again.
Verified. During the testing, Bob makes sure that the button works as expected. Now, a user can change the number of items in the cart using “+”. Bob changes the defect status to Verified.
Closed. Susie sees that the problem is solved and closes the task.
To Sum Up
A bug life cycle ends with defect resolution and marking the problem as closed. However, it opens the next stage of the release cycle: regression testing. After everything is fixed, QA engineers check the system (or at least business-critical features) to see if recent code changes haven’t affected the rest of the functionality. In other words, it is necessary to make sure that the fixing hasn’t broken what was working well. And if it has, there starts another bug life cycle 😉