A defect in simple terms could be understood as ab Flo or an error in an application that restricts the normal flow of an application by matching the expected behavior of an application with the actual one. The defect occurs when a developer makes any mistake during a design or building of an application, and when a tester finds this flaw, it is termed as a defect.
It is the tester’s responsibility to perform precise testing of an application for finding as many defects as possible to ensure that a quality product is going to reach the customer. It is essential to understand the defect life cycle before moving to the defect’s workflow and different states.
Hence, let’s know more about the defect life cycle.
So far, we have discussed the meaning of defect and its related context to the testing activity. Now let’s move towards the defect life cycle in software testing life cycle and understand the flaws workflow and the different states of a defect.
Defect life cycle in detail
A defect life cycle is also known as a bug life cycle, is a cycle of the defect from which date passes through, covering the various states in its entire life. It starts as soon as any new defect is discovered by the tester and comes to an end when the tester clauses that defect assuring it won’t get generated again.
It is now the time for understanding the actual workflow of a defect life cycle:
New: It is the first state of a defect in the defect life cycle. When any new defect is discovered, it falls under the new condition, and validations and testing are performed on this defect in the later stages.
Assigned: A newly created defect is given to the development team for working on the defect in this stage. It is appointed by the project lead or the manager of the testing team to a developer.
Open: The developer commences analyzing the defect and works towards fixing it if required. Suppose the developer feels that the defect is not appropriate. In that case, it could get transferred to any of the four states, namely, duplicate, deferred, rejected, or not a bug depending upon a particular reason.
Fixed: While the developer finishes the task of fixing a defect by making the required changes, they can mark the defect status as fixed.
Pending retest: After the defect is fixed, the developer allot the defect to the tester for retesting the defect at their end until the tester works on protecting the defect; the state of the defect remains in the pending retest.
Retest: The tester commences working on the defect’s retesting to verify if the defect is fixed carefully by the developer as per the requirements or not at this point.
Reopen: If any issue continues in the defect, it will be assigned to the developer again for testing, and the situation of the defect gets changed to reopen.
Verified: If any issue in the defect after being assigned to the developer for retesting is not found. They feel that the defect status is assigned to verify if the defect has been fixed accurately.
Closed: When the defect does not exist any longer, the tester changes the defect status to closed.
Rejected: If the developer’s defect is not considered a genuine difference, it could be marked as rejected by the developer.
Duplicate: If the developer finds the fault the same as any other defect or if the defect matches any other defect, then the defect’s state is changed to duplicate.
Deferred: If the developer feels that the defect is not very prior and could be fixed in the next release, then the defect’s status is changed as deferred.
Not a bug: If the defect does not impact the application’s functionality, then the status of the defect is changed to not a bug.
When a test records any new bugs are built, the compulsory fields submit on, product, module, severity, synopsis, and description for reproducing.
We can add some optional fields in the above list if you are using a manual bug submission template. Customer name, browser, operating system, file attachments and screenshots are included in these optional fields.
The following fields remain other specified or blank
Suppose we have the authority to add bug status, priority, and assigned to the field. In that case, we can designate these fields unless the test manager will set status, bug priority and assign the bug to the respective module owner.
Look at the following defect cycle
The above image details, and when we consider the significant steps in the bug life cycle, we make it a good idea about it. On successful lumbering, the bug is reviewed by the development or test manager. The test manager can set the bug status as open and assign the bug to a developer or delay it until the next release.
When a bug is assigned to a developer, they can start working on it, and the developer can set the bug status as won’t fix, couldn’t reproduce, need more information or fixed. If the developer’s bug status either needs more info or fixed, you respond with a specific action. If the bug gets fixed, we verify the bug and set the bug status as verified, closed or reopened.
Some guidelines for implementing defect life cycle
Testers can adopt some important guidelines before starting to work with the defect life cycle. These are as follows:
- It is essential that the whole team clearly understands different states of the defect, as discussed above, before starting to work on the defect life cycle.
- Testers should properly document the defect life cycle to avoid any confusion in the future.
- Ensuring that each individual who has been authorized any task related to the defect cycle should understand their responsibility for better results.
- The tester should handle the defect tracking tool with care to maintain consistency among the defects and the defect life cycle workflow.
It was all about the defect life cycle and management. We hope you must have to gain tremendous knowledge about the life cycle of a defect.