Introduction
Software testing is a complex job, as the quality of your software product greatly depends on it. QA testers and developers work hard on finding and fixing software bugs in a software product. To make this process more efficient and productive, there’s a proven method that we call a defect life cycle.
In this post, you’re going to learn about several important aspects of the defect life cycle in software testing.
Let’s begin with the simple definition of a defect/ bug.
What is Defect in Software Testing?
If we explain a defect or bug in easy words, it’s a mistake or an error in the software. While developers work on developing the software, they naturally do some human errors. Consequently, there arises a software bug or defect in a software product.
Bugs are basically the flaws in the software. You can’t say defects arise due to negligence because no matter what effort you put in, you still get bugs. However, you can always refine your processes to minimize the occurrence of bugs in the first place.
What is Bug?
You might have questions in mind regarding defect vs bug. Well, there’s no difference between bug and defect and they’re just two different words for the same thing. So a bug means a defect or an error.
It’s essential to find and fix these defects/bugs in your software product to meet the expectations of your client. It comes under the responsibility of the QA tester to make the application defect-free. Therefore, they use different tools and techniques to fix bugs in the software. This process is called software testing where testers test the software to find bugs. Once you find all the bugs, you have to work on fixing them.
Before we move on to other important aspects of this topic, let’s get the idea of the defect life cycle.
What is Defect Life Cycle?
We can put defect life cycle in easy words as the set of states a defect or a bug goes through during its lifetime. It’s also called the bug life cycle in software testing.
Defect management life cycle is a systematic process that helps manage and coordinate the status of the bug. It makes the communication about the defect’s status easier among several assignees. That’s how we can make this process more efficient.
Defect Status
Defect status can be described as the current status of the bug through which it’s undergoing. The basic purpose of defect status is to pass on the present state/status of the defect to the team. This way, you can easily understand and track the progress of the bug and bug lifecycle.
It depends on the kind of project you’re working on that how many states your project’s defect life cycle has to go through. Let’s check out the states of the defect life cycle.
Defect Life Cycle States
These are the states of the defect life cycle.
New
The status of the defect is titled as NEW when we get a new bug and we log and post it for the first time.
Assigned
When you post the NEW bug, the QA tester approves and assigns it to the team of developers. This state of the defect is called ‘Assigned.’
Open
When developers start working on the bug, the state is called ‘Open.
Fixed
Then the developer works to fix the bug and make some changes in the code. When he verifies the change then the status of the defect becomes ‘Fixed.’
Pending Retest
In this stage, developers send the particular code to the tester that they recently have changed to fix the code. They send the code for retesting. As this task remains pending in the hands of the test, we call this status a ‘pending retest.’
Retest
In this stage, the tester retests the code that the developer has sent. The test runs the code and checks if the code fixes the bug. This phase is called ‘Retest.’
Verified
The tester receives the code from the developer and retests it to check if the bug is fixed. If the software becomes bug-free, it means the code has worked fine and the bug is fixed. Then the status is changed to ‘verified.’
Reopen
Sometimes after fixing the bug, the bug still persists. In such a case, the bug has to go through the bug life cycle in testing once again. The status is changed to ‘reopened.’
Closed
Once the bug goes through the above stages and gets fixed, the status is assigned as Closed.’
Duplicate
In this process, if the defect is found twice, the tester assigns the status to ‘duplicate.’
Rejected
If the defect is not a genuine defect that it’s given the status ‘rejected.’
Deferred
If the found defect is of low priority, we can fix it in the later stages of the software testing. So this stage is referred to as ‘Deferred.’
Not a Bug
If we find a bug but it doesn’t have any impact on the software’s functionality, it’s put on the status “Not a bug”.
| States | |||
| Serial No. | Initial | Returned | Confirmation |
| 1 | Collect all the information and pass it on to the person who may reproduce the bug. | When the defect gets rejected or more information is required. | When the bug is successfully fixed, tested, and then closed. |
| 2 | In the initial state of NEW or Open | When there’s a need to clarify and the states are rejected. | When the states are verified and resolved. |
Wrapping Up
The defect life cycle is extremely important in making the software testing process more productive. In this post, you’ve learned from scratch about the bug and the defect life cycle. Then you walked through several states of the defect life cycle.
Now you have a clear idea of how we find and fix the bug through a defect life cycle. This bug cycle is a proven, results-driven methodology that has numerous benefits. And that we will discuss in detail in our upcoming posts.
And as we always say, we really appreciate your participation. You can always write down your thoughts in the comments.