Defect Life Cycle In Software Testing
You all might know what SDLC (Software Development Life Cycle) is. But are you familiar with the Defect Life Cycle or Bug Life Cycle in Software Testing? Many of us will be unaware of this. So, in this article, we will go over the Defect Life Cycle in depth.
The first question that you might want to get the answer to would be: What is Defect Life Cycle? So, here is the answer and the definition of the Defect Life Cycle so that you can better understand the topic.
You can also explore: Software Testing Online Courses & Certifications
Defect Life Cycle Definition: Defect Life Cycle, or Bug Life Cycle, is the particular set of stages a defect or bug goes through throughout its life.
Now that you have some idea of what a Defect Life Cycle or Bug Life Cycle is let’s move ahead and explore the topic in depth. But first, let’s go over the topics listed in the table of contents (TOC) that we’ll be covering in this article.
You can also explore these articles related to software testing:
Table Of Contents (TOC)
- What is Defect Status or Defect State?
- Defect Life Cycle States
- Defect Life Cycle – A Detailed Explanation Using Example
- What is the Main Objective or Purpose of the Defect Life Cycle?
- Conclusion
What is Defect Status or Defect State?
“Defect Status or Defect State is the current state/status of the defect/bug in the defect life cycle.”
Depending on the type of project, the defect goes through various defect states throughout its life cycle, making it difficult for testers or developers to distinguish which defects or bugs have been resolved, which are still in process, which defects must be retested, and so on.
The use of Defect State is to precisely identify and convey the current state of a defect/bug so that you can easily track the Defect Life Cycle.
You can also explore: Functional testing and its types
Best-suited Quality Assurance & Testing courses for you
Learn Quality Assurance & Testing with these high-rated online courses
Defect Life Cycle States
A Defect Life Cycle or Bug Life Cycle consists of the following states:
S.No | State | Description |
---|---|---|
1 | New | This state is assigned when a new bug is found or reported. |
2 | Assigned | This state is assigned once the team leader assigns a bug to the developer team. |
3 | Open | This state is assigned once the defect is with the developer team and they have started working on it. |
4 | Fixed | The developer team assigns this state once the defect has been resolved or fixed. |
5 | Pending retest | This state is assigned for the duration a developer solves the problem, and a tester starts reviewing whether the defect has been corrected. |
6 | Retest | This state is assigned when testers test whether the developers have resolved the defect. |
7 | Verified | This state is assigned when testers confirm that the defect has been resolved. |
8 | Reopen | The state is assigned when the tester finds that the defect has not been resolved; hence they reopen the defect. |
9 | Closed | The state is assigned once the defect has been resolved and the defect is already in the verified state. |
Apart from these Defect State, there are some other states/status as well. Let’s explore those as well:
S.No | State | Description |
---|---|---|
1 | Duplicate | This state is assigned when the same defect/bug is reported twice or corresponds to the same concept of the defect/bug. |
2 | Rejected | This state is assigned when developers find that the defect reported is not genuine, logical, or legitimate. |
3 | Deferred | This state is assigned when the reported defect/bug is not a top priority and will be fixed in the next release. |
4 | Not a bug | This state is assigned when the developers find that no functionality is being affected because of the defect or the defect was because of some issue (not complete knowledge regarding how to use, power cut, etc.) at the client end. |
Here’s a graphical representation of all states/status:
Defect Life Cycle – A Detailed Explanation Using Example
In order to understand the Bug Life Cycle, let’s go through an example. In this example, you are a developer.
- Assume a testers finds a defect/bug. (Defect state: New)
- The team leader assigned the bug to you. (Defect state: Assigned)
- You received the details related to the defect and started working on it. (Defect state: Open)
- After working on the defect, you successfully resolved it. (Defect state: Fixed)
- For the time duration between a developer solving the problem and a tester starting reviewing whether the defect has been corrected, the defect state remains as Pending Retest.
- The testers start rechecking whether the developers have resolved the defect. (Defect status: Retest)
- Testers confirm that the defect has been resolved. (Defect status: Verified)
- The defect has been resolved and is already in the Verified state. (Defect Status: Closed)
This is how a typical life cycle works and here’s a graphical representation:
You can also explore these articles, related to software testing:
What is the Main Objective or Purpose of the Defect Life Cycle?
The main objective of the this life cycle is to efficiently communicate or inform the current status of the bug from one tester to another. Once you, as a tester, know the state of the defect or the bug, it will help you make the defect-fixing process quite efficient and systematic.
In order to understand the purpose or importance of the this life cycle, let’s take an example. Suppose you are working as a tester in an organization. You are a member of a team of five testers. You received an email one day informing you about the two bugs reported by a client.
Assume the first bug has the id 001 and the defect state is “Open,” and the second has the id 002 and the defect state is also “Open.”
You began working on bug OO1. While you were still working on 001, one of your colleagues began working on 002. After some time, you noticed that the bug with 002 bug id has the defect state as “Fixed.” When you looked at the defect state, you realized that the bug had been fixed or resolved.
Hence, the Defect State helps to easily communicate or inform the defect’s current status and makes the defect-fixing process quite efficient and systematic.
Conclusion
A Defect/Bug life cycle is a cycle that a defect goes through throughout its entire life. It starts when a defect is discovered and ends when the defect is closed after the defect or bug has been resolved.
Anshuman Singh is an accomplished content writer with over three years of experience specializing in cybersecurity, cloud computing, networking, and software testing. Known for his clear, concise, and informative wr... Read Full Bio