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.
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.
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.
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.
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:
If the problem is reproducible and obvious, the developer starts working on fixing it.
As soon as the developer makes changes to the code, the bug goes to Fixed.
The task returns to the QA specialist, who checks if the problem is actually solved.
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.
If a QA specialist confirms that the bug has been fixed, the status changes to Verified.
Closed is a status that marks the final stage of the bug life cycle. The work is done.
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:
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.
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:
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.
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 😉
The saturated mobile app market makes businesses constantly reimagine the definition of quality. This never-ending…
Over half of the software companies use test automation. And almost all testing pros rely…
Imagine studying a language without dictionaries or manuals. Could you learn what each word means…
For QA engineers, learning is a never-ending journey. While you can always expand and refresh…
Everyone can write decent functional test cases. Writing documentation for functional testing services that have…
Automation is now a priority. Nearly all QA specialists write automation scripts for their projects.…