The simplest definition of a defect is an error or flaw in an application that prevents it from operating normally by causing it to behave differently than expected.
When a developer makes a mistake when developing or building an application, it is referred to as a defect when a tester discovers what went wrong.
An application must be thoroughly tested by a tester in order to identify as many flaws as possible and guarantee that the customer will receive a high-quality product. Before proceeding to the process and various defect states, it is crucial to comprehend the defect life cycle.
Hence, let’s talk more about the Defect Life Cycle.
So far, we have discussed the meaning of defect and its relation in context to the testing activity. Now, let’s move to the defect life cycle and understand the workflow of a defect and the different states of a defect.
Defect Life Cycle in Detail
The Defect existence Cycle, sometimes referred to as the Bug Life Cycle, is a cycle of faults that it experiences during its existence, encompassing the various phases. This begins as soon as a tester discovers a new flaw and ends when the tester fixes the flaw and guarantees that it won’t be replicated.
Defect Workflow
It is now time to understand the actual workflow of a Defect Life Cycle with the help of a simple diagram as shown below.
Defect States
#1) New: This is the first state of a defect in the Defect Life Cycle. When any new defect is found, it falls in a ‘New’ state, and validations & testing are performed on this defect in the later stages of the Defect Life Cycle.
#2) Assigned: In this stage, a newly created defect is assigned to the development team to work on the defect. This is assigned by the project lead or the manager of the testing team to a developer.
#3) Open: Here, the developer starts the process of analyzing the defect and works on fixing it, if required.
If the developer feels that the defect is not appropriate then it may get transferred to any of the below four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon a specific reason. We will discuss these four states in a while.
#4) Fixed: When the developer finishes the task of fixing a defect by making the required changes then he can mark the status of the defect as “Fixed”.
#5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester to retest the defect at their end, and until the tester works on retesting the defect, the state of the defect remains in “Pending Retest”.
#6) Retest: At this point, the tester starts the task of retesting the defect to verify if the defect is fixed accurately by the developer as per the requirements or not.
#7) Reopen: If any issue persists in the defect, then it will be assigned to the developer again for testing and the status of the defect gets changed to ‘Reopen’.
#8) Verified: If the tester does not find any issue in the defect after being assigned to the developer for retesting and he feels that if the defect has been fixed accurately then the status of the defect gets assigned to ‘Verified’.
#9) Closed: When the defect does not exist any longer, then the tester changes the status of the defect to “Closed”.
A Few More:
- Rejected: If the defect is not considered a genuine defect by the developer then it is marked as “Rejected” by the developer.
- Duplicate: If the developer finds the defect as same as any other defect or if the concept of the defect matches any other defect then the status of the defect is changed to ‘Duplicate’ by the developer.
- Deferred: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as ‘Deferred’.
- Not a Bug: If the defect does not have an impact on the functionality of the application, then the status of the defect gets changed to “Not a Bug”.
Build version, Submit On, Product, Module, Severity, Synopsis, and Description to Reproduce are the required fields where a tester must record any new bugs.
If you are using a manual bug submission template, you can add some optional fields to the list above. Customer name, operating system, browser, file attachments, and screenshots are examples of these optional fields.
The following fields remain either specified or blank:
If you have the authority to add bug Status, Priority, and ‘Assigned to’ fields then you can specify these fields. Otherwise, the Test Manager will set the status and Bug priority and assign the bug to the respective module owner.
Look at the following Defect cycle
You may get a fast overview of the Bug Life Cycle by looking at the above figure, which is pretty thorough.
The bug was examined by the Development and Test management once it was successfully logged. Test managers have the option to designate a bug as open, assign it to a developer, or postpone it until the following release.
A developer can get to work on an issue as soon as it is assigned to them. The developer has the option to mark a bug as “Fixed,” “Won’t fix,” “Couldn’t reproduce,” or “Needs more information.”
The QA takes a specified step in response if the developer sets the bug status to either “Need more info” or “Fixed.” Once the bug has been fixed,the QA verifies the bug and can set the bug status as verified closed or Reopen.
Guidelines for Implementing a Defect Life Cycle
Before beginning to use the Defect Life Cycle, a few crucial rules might be followed.
They are as follows:
- It is crucial that the entire team comprehends the many stages of a defect (described above) before beginning to work on the Defect Life Cycle.
- It is important to accurately document the defect life cycle to prevent future misunderstandings.
- For better outcomes, make sure that everyone assigned a task pertaining to the Defect Life Cycle is well aware of their responsibilities.
- Every person who is altering a defect’s status should be fully aware of it and give sufficient information about it and the rationale behind it so that all those working on that specific defect can quickly comprehend why the defect has been given that status.
- The tracking of defects tool should be handled with care to maintain consistency among the defects and thus, in the workflow of the Defect Life Cycle.
Let’s now talk about the Defect Life Cycle-based interview questions.
Frequently Asked Questions
Q #1) What is a defect in the perspective of Software Testing?
Answer: Any fault or flaw in an application that prevents it from operating normally by causing a discrepancy between the expected and actual behavior of the application is called a defect.
Q #2) What is the major difference between Error, Defect, and Failure?
Answer:
Error: If the developers find that there is a mismatch in the actual and expected behavior of an application in the development phase then they call it an Error.
Defect: If testers find a mismatch in the actual and expected behavior of an application in the testing phase then they call it a Defect.
Failure: If customers or end-users find a mismatch in the actual and expected behavior of an application in the production phase then they call it a Failure.
Q #3) What is the status of a defect when it is initially found?
Answer: When a new defect is found, it is in a new state. This is the initial state of a newly found defect.
Q #4) What are the different states of a defect in the defect life cycle when a defect is approved and fixed by a developer?
Answer: Different states of a defect, in this case, are New, Assigned, Open, Fixed, Pending Retest, Retest, Verified, and Closed.
Q #5) What happens if a tester still finds an issue in the defect that is fixed by a developer?
Answer: The tester can mark the state of the defect as . Reopen if he still finds an issue with the fixed defect and the defect gets assigned to a developer for retesting.
Q #6) What is a producible defect?
Answer: A defect that is occurring repeatedly in every execution and whose steps can be captured in every execution, then such a defect is called a “producible” defect.
Q #7) What type of defect is a non-reproductible defect?
Answer: A defect that is not occurring repeatedly in every execution and is producing only at some instances and whose steps as proof have to be captured with the help of screenshots, then such a defect is called as a no reproducible.
Q #8) What is a defect report?
Answer: A defect report is a document that includes reporting information about the defect or flaw in the application which is causing the normal flow of an application to deviate from its expected behavior.
Q #9) What details are included in the defect report?
Answer: Defect ID, defect description, feature name, test case name, reproducible defect or not, defect status, defect severity, and defect priority are all included in a defect report. Name of tester, date of defect testing, build version where the flaw was discovered, developer to whom the defect was assigned, and name of someone who corrected the defect screenshots of a flaw showing how the procedures are carried out, fixing the flaw’s date, and identifying the approver.
Q #10) When is a defect changed to a ‘deferred’ state in the defect life cycle?
Answer: When a defect that is found is not of very high importance and the one which can get fixed in the later releases are moved to a ‘deferred’ state in the Defect Life Cycle.
Additional Information on Defect or Bug
- At any stage of the software development life cycle, a fault could be introduced.
- The smaller the total cost of quality, the sooner the defect is found and fixed.
- Removing a defect within the same phase that it was introduced reduces the cost of quality.
- Static testing identifies the flaw rather than the failure. Because debugging is not required, the expense is kept to a minimum.
- In dynamic testing, a flaw is discovered when it results in a failure..
States of Defect
| S.No. | Initial State | Returned State | Confirmation State |
|---|---|---|---|
| 1 | Gather information for person responsible for reproducing the Defect | Defect is Rejected or asked for more information | Defect is Fixed and should be tested and closed |
| 2 | States are Open or New | States are Rejected or Clarification. | States are Resolved and Verification. |
Invalid and Duplicate Defect Report
- Defects can occasionally arise from the test environment or misunderstanding rather than the code; in these cases, the report should be closed as invalid.
- When there are double reports, one is closed as a duplicate and the other is maintained. The manager accepts certain reports that are deemed invalid.
- The Defect Management tool cross-functional team is often in charge of managing the reports, while the Test Manager is in charge of the entire Defect Management and process.
- Test managers, developers, project managers, production managers, and other relevant stakeholders are among the participants.
- The Defect Management committee should determine the validity of each defect and determine when to fix or defer. To determine this, consider the cost, risks, and benefits of not fixing any defect.
- If the defect has to be fixed, then its priority has to be determined.
Defect Data
- Name of the Person
- Types of Testing
- Problem Summary
- Detailed Description of Defect.
- Steps to Reproduce
- Life Cycle Phase
- Work product where Defect was introduced.
- Severity and Priority
- Subsystem or Component where the Defect is introduced.
- Project Activity occurring when the Defect is introduced.
- Identification Method
- Type of Defect
- Projects and Products in which problems exist
- Current Owner
- Current State of the Report
- Work product where Defect occurred.
- Impact on Project
- Risk, loss, opportunity, and benefits associated with fixing or not fixing the defect.
- Dates when various defect lifecycle phases occur.
- Description of how the defect was resolved and recommendations for testing.
- References
Process Capability
- Introduction, Detection, and Removal info -> Improve Defect detection and Cost of Quality.
- Introduction -> Praetor analysis of the process in which the largest number of defects is introduced to reduce the total number of defects.
- Defect Root info -> find underline reasons for the defect to reduce the total number of defects.
- Defect Component info -> Perform Defect Cluster Analysis.
Conclusion
The Defect Life Cycle and Management are the main topics here.
We assume that you have learned a great deal about the life cycle of a flaw. In turn, this instruction will make it easier for you to deal with the flaws in the future.
You may be interested in:
Software testing manual and automation interview questions
Common Manual Testing Interview Questions