Normally, the Software Development Life Cycle (SDLC) protocols are followed by development teams while creating any software product. However, the development process is not always simple and seamless. In fact, various forms of flaws or bugs occur in the product during the development process. As a result, these flaws are recognized and addressed throughout the development process in order to offer a high-quality software product at the end. So, in this post, we'll talk about defects in the software development process, how they're detected during software testing, and how they're fixed.
What is the bug life cycle in software testing?
In software testing, the Defect Existence Cycle or Bug Life Cycle is the exact collection of stages that a defect or bug goes through throughout its life. The goal of the Defect life cycle is to make the defect-fixing process methodical and efficient by conveniently coordinating and communicating the current state of defects as they change to multiple assignees.
What is the bug life cycle in software testing’s workflow?
The bug life cycle workflow is divided into nine parts, as shown below:
1. New
It is at the initial stage of the lifecycle that the problem is discovered. When a new defect is discovered, it is assigned a new state, and the process of testing and validation begins, resulting in new states.
2. Delegated
The newly created bug has been assigned to the appropriate development department for resolution. Typically, the testing team manager assigns defects to the development team.
3. Open
When a developer begins working on the problem, it is in an open state. Developers will begin working on the bug in accordance with the specifications. There is also the possibility that the issue will not appear appropriate; in this case, the developer can transfer the issue to one of these four states for specific reasons.
- Duplicate
- Deferred
- Rejected
- Not a bug
4. Fixed
When the developer takes the appropriate measures and the issues are resolved, the status is marked as fixed.
5. Pending retest
Once a developer has worked on the issue and made the necessary adjustments, it is returned to the tester to be tested again. The time spent waiting for repeated testing is squandered, and the problem stays in the condition of 'Pending Retest.'
6. Repeat the test
The case enters the retest phase when the tester resumes testing the issue. The tester will double-check to see if the developer repaired the problems as required.
7. Reopening
If the requirements are not completed correctly and the problem persists in the function, the tester reopens the bug state.
8. Confirmed
If the problem has no issues and was appropriately repaired by the developer, the bug's state is changed and it is recorded as confirmed.
9. Finished
When a flaw does not exist and is fully evaluated and validated, it results in a closed condition. The tester modifies the defect's status.
The following are some examples of defect life cycles:
- New. A quality assurance tester (let's call him Tom) visits the website of an online bookshop he's evaluating and adds a book to a cart. The item is added to Tom's cart, but he cannot order two identical books. A click on "+" to adjust the number of items has no effect. Tom details the issue and creates a bug report as New.
- Assigned. A PM (let's say, Susan, who is in charge of job delegation) notices a flaw on the list. The issue looks to be real and significant. Susan delegated the work to Brian, a back-end developer who developed the cart feature.
- Open. Brian notices a new task and attempts to duplicate it by following the directions in the report. The "+" symbol does not function as intended. Brian updates the bug status to Open and begins investigating the root cause. However, the case doesn’t always go like that. Brian understands that bugs might be invalid. Instead of designating the While attempting to solve it immediately, he can use an alternative status, such as:
- Duplicate. While reading the report, Brian notices that Peter, another software tester, reported this fault the day before. Brian categorizes the problem as duplicate. There's no need to add it to the task pull again; it's already there.
- Rejected. Brian adds the book to the basket and clicks "+" using the directions from the problem report. The number of things is reduced to two. How is it even possible? Perhaps the issue was caused by an unreliable internet connection. Perhaps the fault occurs on a certain gadget, but Tom failed to mention this information in the description.
- Deferred. The flaw only affects the Firefox browser, which has a limited user base. Brian chooses to fix it later after determining the source of the payment failures. members of the test team's abilities
- Not a bug. Brian is first alarmed but soon discovers Tom attempted to purchase an extra ebook. It's impossible due to website logic: a user may access an ebook from any device, eliminating the need to acquire it twice.
- More information is required. Brian is unsure of the circumstances behind the appearance of the bug. Is the user logging in to his/ her account at the moment? Is Tom attempting to add an item on a product page or at the order confirmation stage?
- It is not repairable. Brian is aware of the situation and has attempted to remedy it several times. It's a difficult bug to identify, and he'll have to go through a large codebase to repair it. Currently, a person may order two books by entering "2" into the box that displays the number of goods.
- Fixed. Brian discovers and corrects a coding error. He then change the progress into Fixed.
- Pending retest. Once the defect has been fixed, the test would be returned to Tom, and waiting for the retesting process.
- Retest. Tom is notified that his status has changed. He has to double-check the functionality and ensure that users may now adjust the number of books. He activates the retest status and begins working.
- Reopened. Unfortunately, Tom learns that the problem still exists throughout the retesting. The number of items does not change when you click "+." The work is reopened and returned to Brian. Brian needs to check into the issue again. The problem will be retested when it has been fixed.
- Verified. During testing, Tom ensures that the button functions as intended. A user may now adjust the number of goods in the basket by pressing "+." Tom updates the status of the defect to Verified.
- Closed. Susan concludes the work after determining that the problem has been resolved.
Final thoughts
A bug life cycle concludes with defect remediation and closing the problem. It does, however, usher in the next stage of the release cycle: regression testing. After everything has been repaired, QA testers examine the system (or at least the business-critical functions) to ensure that recent code modifications haven't impacted the remainder of the functionality. In other words, it is vital to ensure that the repair has not broken what was previously operating properly. And if it has, a new bug life cycle begins.
GCT Solutions works with businesses to implement AI solutions and build modern digital platforms that create measurable operational impact. Our capabilities across AI Services, AI Consulting, Platform Modernization and Software Engineering help organizations scale technology more effectively and accelerate digital transformation initiatives.
Author: Chi Vo - Content Marketing Executive