What is the Defect/Bug Lifecycle in Software Testing? Defect Life Cycle Tutorial
Introduction to Defect Life Cycle
This tutorial will discuss the life cycle of defects to help you understand the different stages that testers must deal with when working in a testing environment.
The most commonly asked questions about the Defect Life Cycle have been added to our website. Understanding the different states of a defect is crucial in order to fully appreciate its life cycle. Testing is done to determine if there are any errors or issues with the product.
In terms of real scenarios, errors/mistakes/faults are all referred to as bugs/defects and hence we can say that the main objective of doing testing is to ensure that the product is less prone to defects (no defects is an unrealistic situation).
The question is: What is a defect?
What is a defect?
A defect is simply a flaw in or error in an app that restricts the normal flow of the application. It is an inconsistency between the expected behavior and the actual behavior.
A defect is a mistake made by a developer while designing or building an application. When this defect is discovered by a tester it is called a defect.
To ensure that the customer receives a high-quality product, a tester must conduct thorough testing on the application. Before you move on to the workflow and the different states of the defect, it is crucial to understand the defect cycle.
Let’s now talk about the Defective Life Cycle.
We have already discussed the meaning and relationship of defect in relation to testing activities. Let’s now move on to the defect lifecycle and explore the various states and workflows of defects.
Details on the Defect Life Cycle
The Defect Life Cycle (also known as the Bug Life Cycle) is a series of defects that covers all phases of a person’s life. This begins as soon as a new defect is discovered by a tester. It ends when the tester closes that defect to ensure that it doesn’t happen again.
Now it is time to look at the Defect Life Cycle in detail with this simple diagram.
#1: New is the initial state of a defect during the Defect Lifecycle. Any new defect that is discovered falls in a “New” state. Validation and testing are done on the defect during the later stages in the Defect Lifecycle.
#2) Assigned At this stage, a new defect is created and assigned to the development team for them to fix. This assignment is made by the project leader or manager of the testing group to a developer.
#3:Here the developer begins the process of analysing the defect and working to fix it, if necessary.
Developers who feel that the defect is inappropriate may transfer it to one of the following four states Duplicate (Deferred), Rejected (or Not a Bug) based on a specific reason. These four states will be discussed in detail later.
#4: Fixed: When the developer has completed the task of fixing the defect and made the necessary changes, he can mark the defect status as “Fixed”.
#5) Pending Test:After fixing the problem, the tester assigns it to the developer to retest it at their end. Until the tester works to correct the defect, the state is still in “Pending Review”.
#6) Retest At this point, the tester will begin to test the defect again in order to confirm that the developer has fixed the problem correctly.
#7) Reopen If there is a problem with the defect, it will be re-assigned to the developer for further testing. The defect status will then change to ‘Reopen’.
#8 Verified: If the tester finds no issue with the defect, and feels that the defect has been corrected accurately, then the defect status is ‘Verified.
#9) Closed When the defect is no longer present, the tester will change the defect status to “Closed”.
A Few Other:
- Rejected If the defect is not considered to be a genuine defect, it will be marked “Rejected” by developer.
- Duplicate If the developer finds that the defect is the same as any other defect, or if the defect concept matches any other defect, then the status of defect is changed by the developer to ‘Duplicate.
- Deferred If the developer feels the defect is not very important and can be fixed in the next releases, or in such a case the developer can make the defect ‘Deferred.
- Not a bug: If the defect has no impact on the functionality, the status of the defect is changed to “Not a Problem”.
The fields that a tester must fill out to report any new bugs are: Build version, Submit on, Product, Modules, Severity and Synopsis.
If you’re using a manual bug submission template, you can add optional fields to the above list. These optional fields include customer name, browser, operating system, file attachments, and screenshots.
The fields below remain either blank or specified:
These fields can be added if you have the authority to change bug status, priority, and assign to fields. If not, the Test Manager will assign the bug to its owner and set Bug priority.
Take a look at the following Defect Cycle
This image is very detailed. When you think about the important steps in Bug Life Cycle, you’ll get a good idea of it.
After successful logging, the bug was reviewed and approved by the Test and Development manager. The bug status can be set by Test managers to Open. They can also Assign the bug the developer, or it may be delayed until the next release.
A bug can be assigned to a developer and he/she will begin working on it. A developer can assign a bug to a developer and set its status to won’t fix or could not reproduce.
The QA will respond to a bug report if the status is “Need more information” or “Fixed”. If the bug has been fixed, the QA verifies it and can then set the bug status to either closed or reopened.
Guidelines for Implementing a Life Cycle of Defects
Before you begin to work with the Defective Life Cycle, there are some important guidelines.
These are the following:
- It is important that the entire team understands the Defect Life Cycle before they begin to work on it (described above).
- To avoid confusion in the future, it is important to properly document the defect life cycle.
- For better results, ensure that everyone who is assigned a task in the Defect Life Cycle understands his/her responsibility.
- Every person who changes the status of defect should be aware of it and should give enough information about the defect and the reasons for it so that all those working on the defect can easily understand why.
- You should use the defect tracking tool with care in order to preserve consistency among defects and the Defect Lifecycle workflow.
Let’s now discuss the questions that were asked about the Defect Life Cycle.
Most Frequently Asked Questions
Q #1: What is a defect from the perspective of Software Testing
Answer: Any kind of flaw in an application that restricts the normal flow of the application’s functionality by mismatching its actual behavior with its expected behavior.
Q #2: What is the main difference between error, defect, and failure?
Error If developers discover that an application’s behavior is not consistent with what they expected, then they label it an Error.
Defect: When testers discover a difference between the expected and actual behavior of an app during testing, they call it a “Defect”.
Failure Customers and end-users can call an application a failure if it exhibits a different behavior than expected during production.
Q #3: What is the status a defect in its initial discovery?
Answer to A new defect is one that has been discovered. This is the first state of a newly discovered defect.
Question #4: What are the states of a defect during the defect lifecycle?
Answer : In this instance, there are five states that indicate a defect.
Q #5: What happens if a tester finds an issue with a defect that has been fixed by a programmer?
Answer: A tester can mark the defect’s state as “fixed”. If he finds an issue, he can reopen the test and assign the defect to a developer for further testing.
Q #6 What is a Producible Defect?
Answer: If a defect occurs repeatedly and can be tracked in each execution, it is known as a “producible defect”.
Q #7) Which type of defect is non-reproducible?
Answer to If a defect does not occur repeatedly and only in certain instances, and whose steps are documented with screenshots, it is called a no reproducible.
Q #8 What is a defect reporting?
Answer: The defect report contains information about the flaw or defect in an application that is causing it to behave differently than expected.
Q #9: What information is included in the defect investigation?
Answer: The defect report contains the following information: Defect ID, description of defect, Test Case Name and Tester Name. Build Version in which defect was discovered. Developer assigned to fix it. Screenshots showing the process of fixing the defect. Also, names of those who have approved the defect.
Q #10) How is a defect made to a ‘deferred state’ in the defect lifecycle?
Answer: A defect that has been found and isn’t of high importance, but can be fixed in later releases, is moved to a “deferred” state in the Defect Lifecycle.
Additional Information On Defect Or Bug
- Any point in the Software Development Life Cycle can have a defect.
- The earlier the defect is found and fixed, the lower the quality cost.
- Quality is at its lowest when it is eliminated in the same phase as it was introduced.
- Static testing identifies the problem and not the failure. Because debugging is not required, the cost of static testing is minimal.
- When a defect causes a failure in Dynamic testing, it is deemed to be present.
States of Defect
|S.No.||Initial State||Returned state||Confirmation Status|
|1||Collect information about the person responsible for reproducing your defect||Ask for more information or rejection of the defect||Defect is fixed and should be closed|
|2||States are either open or new||States are either rejected or clarified.||States are resolved and verified|
Invalid and duplicate Defect Report
- Sometimes defects can occur not due to code, but because of test environments or misunderstandings. Such a report should then be closed as an invalid defect.
- Duplicate Reports are kept one and closed the other. The Manager will accept invalid reports.
- The overall Defect Management process is overseen by the Test Manager. Reports are managed by the Defect Management Tool cross-functional team.
- Participants include Test Managers and Developers, PMs, Production Directors, and any other interested parties.
- Defect Management committees should assess each defect to determine its validity and decide when it is best to fix or defer. Consider the costs, risks, and benefits to not fixing any defect.
- If the defect must be fixed, then it is important to determine its priority.
- Name of the person
- Different types of testing
- Problem Summary
- Detail Description of the Defect
- Steps to reproduce
- Phases of the Life Cycle
- Product for which Defect was introduced.
- Priority and severity
- The Defective Subsystem or Component is found in the following:
- When the Defect is introduced, Project Activity occurs.
- Method of Identification
- Type of defect
- Problems in projects and products
- Current Owner
- The Report’s Current Status
- Product where defect occurred
- Impact on Project
- There are risks, losses, opportunities, and benefits to fixing or not fixing the defect.
- When various phases of the defect lifecycle occur.
- Description of the defect and testing recommendations.
- Refer to
- Information about Defects: Introduction, Detection and Removal -> Increase Quality and Reduce Cost.
- Introduction -> Praetor analysis to determine the most significant defect in a process. This is used to reduce the number of defects.
- Information on the Defect Root -> Find the underline reasons for the defect in order to reduce the number of defects.
- Defect Component info -> Perform Defect Cluster Analysis.
It all comes down to the Management and Life Cycle of Defects.
We hope that you have gained a lot of knowledge about the life cycle a defect. This tutorial will help you to deal with future defects in an efficient manner.