✖️Defect Life Cycle

Defect Life Cycle or Bug The life cycle in software testing is the specific set of states that a defect or bug goes through in its entire life.

The purpose of the defect life cycle is to easily coordinate and communicate the current status of the defect, which changes to various assignee's and make the defect fixing process systematic and efficient.

Introduction

As a software testing professional, understanding the defect life cycle, also known as the bug life cycle, is crucial to ensuring changes, software quality.

In this tutorial, we’ll explore the stages of the defect life cycle and their importance in ensuring software quality.

Overview

We can define the defect/bug as the abnormal behavior of any software. The defect life cycle is a process that describes the stages of a defect from discovery to closure. By following the defect life cycle, we can ensure that defects are discovered, documented, and resolved in a structured and efficient manner.

The Stages of the Defect Life Cycle

We have seven steps in the defect life cycle. Let’s look at each one of them in the following subsections.

Stage	Description	Example Scenario
1️⃣ Defect Discovery	A defect is discovered during testing.	🚀 A user reports that the application crashes when they try to upload a file.
2️⃣ Defect Logging	The defect is logged in a defect tracking tool with details such as the defect description, severity, and priority.	📝 The QA engineer logs the defect in the tracking tool with a description of the issue and assigns it a high priority.
3️⃣ Defect Assignment	The defect is assigned to the appropriate developer or team to fix the issue.	👥 The QA lead assigns the defect to the development team responsible for the affected module.
4️⃣ Defect Fixing	The developer fixes the defect and verifies the fix, ensuring that the defect is resolved.	🔧 The developer fixes the issue and unit tests the code to ensure that the fix works as expected.
5️⃣ Defect Verification	The QA team verifies the fix and retests the software to ensure that the defect is no longer present.	✅ The QA engineer tests the fix and verifies that the issue is resolved, then updates the defect tracking tool with the test results.
6️⃣ Defect Closure	The defect is closed once it is verified that it has been fixed and is no longer present in the software.	🚪 The QA lead reviews the test results and closes the defect in the tracking tool if the issue has been resolved.

3.1. Defect Discovery

Everything starts by discovering that a defect exists.

We can discover defects during various stages of software development, such as design, coding, testing, or even after the software has been released. For example, during the testing phase, a tester may encounter a functionality issue or unexpected software behavior, which indicates a defect.

3.2. Defect Logging

Once we discover the defect, we must log it into a defect tracking tool, such as JIRA, Bugzilla, or Trello. This process involves capturing as much information as possible about the defect, such as its severity, priority, and steps to reproduce it.

Let’s consider a software-:crashing example scenario. A tester may log this defect with the following information:

• Description: The software crashes when the user clicks the “Save” button

• Severity: High (the defect causes a critical system failure)

• Priority: Urgent (the defect needs to be fixed before the software can be released)

• Steps to reproduce: 1. Open the software; 2. Create a new file; 3. Type some text; 4. Click on the “Save” button

3.3. Defect Triage

In this phase, the project manager reviews and assigns the defect’s severity and priority. The severity level indicates the impact of the defect on the system, while the priority level indicates the urgency to fix the defect.

For example, a critical defect with a high priority may need to be fixed immediately to avoid causing significant damage to the system or the end-user experience.

3.4. Defect Assignment

After triaging a defect, we should assign it to a developer who will work on resolving the defect. The developer receives all the necessary information about the defect, such as its reproduction steps and the expected behavior to resolve the issue.

3.5. Defect Fixing

The developer starts working on fixing the defect. Once the developer completes the fix, they mark the defect as “Fixed” in the defect tracking tool.

For example, a developer may fix the above-mentioned defect by identifying the code responsible for the crash and correcting it. After the fix is complete, the developer marks the defect as “Fixed”.

3.6. Defect Verification

After fixing the defect, we need to verify the fix. The tester verifies this by executing the test cases related to the defect. If the tester finds the fix does not solve the defect, it is reassigned/reopened.

For example, a tester may verify the fix for the above-mentioned defect by repeating the steps to reproduce the issue and checking that the software no longer crashes when clicking the “Save” button.

3.7. Defect Closure

Once the defect has been verified, it is marked as “Closed” in the defect tracking tool. The defect is considered closed when it meets the criteria for closure, such as passing all the related test cases and receiving approval from the project manager.

3.8. Life Cycle Summary

Let’s look into the visual representation of the various stages that a software defect goes through, from its discovery to closure:

As we can see, the defect life cycle involves multiple stages, from triaging and assigning defects to developers for fixing to verifying the fix. If a previously closed defect is found to have a similar issue, it may be reopened and assigned for fixing again.

Sometimes, after a bug has been reported and worked on, it goes through a few different states before it is resolved. Here are some examples of those states:

• Rejected: If a developer disagrees with a bug report from a tester and considers it’s not a problem or something that needs to be fixed right now, it can be marked as “Rejected”

• Duplicate: If the reported bug is the same as another bug already in the “Open” state or fixing a different bug will also take care of this one, it can be marked as a “Duplicate” so we don’t waste time working on it separately

• Deferred: Sometimes, we may decide that a bug doesn’t have a high priority – maybe it’s not a big problem, or it would be too difficult or expensive to fix right now. In that case, we can mark the bug as “Deferred” and plan to work on it in a future release of the software

• Not a Bug: If we investigate a bug report and find that it’s not really a problem – maybe it’s just a misunderstanding or something that doesn’t affect the software’s performance – we can mark it as “Not a Bug”. In such a way, we can focus on the other relevant defects that must be fixed

The Defect Life Cycle in Agile Environment

The defect life cycle in Agile Environment differs from traditional software development because it is iterative and incremental.

Agile methodologies involve continuous testing and integration, which allows defects to be discovered and addressed early in development.

The stages in the defect life cycle in the agile environment include discovery, logging, triage, assignment, fixing, testing, and closure. But, unlike traditional software development, these stages are not always linear and may overlap or simultaneously happen.

For example, defects may be discovered during testing and immediately fixed by the developer without going through the triage and assignment stages.

Roles in the Defect Life Cycle 👥

• Tester - Logs defects, retests fixes 🕵️

• Developer - Fixes defects 👨‍💻

• QA Manager - Reviews and prioritizes defects 💼