A Comprehensive Guide of Understanding Defects and Bugs in Software testing
The period between the beginning detection of a bug (marked as 'New') and its successful closure (marked as 'Closed'), rejection, postponement, or deferral is known as the 'Bug/Error Life Cycle'. This mentions the altered level that a bug goes through from its discovery to its resolution, and how it is managed and tracked throughout the process.
Defect life cycle is a crucial part of software testing, and it is the process that a defect goes through from detection to resolution. In this blog, we will discuss the defect lifecycle for testing with practical examples.
Defect Lifecycle covers the different stage that follows defect.
Defect Detection: The first stage of the defect lifecycle is the detection of the defect. Defects can be detected by testers during testing. Testers can detect defects while performing various types of testing, such as functional testing, usability testing, performance testing, etc. For example, a tester may find a defect while performing functional testing of a login screen.
Defect Logging: Once a defect is identified, the next step is to log the defect. The defect logging process involves documenting the details of the defect, such as its severity, priority, and steps for reproducing the defect. For example, the tester logs the defect in a defect tracking tool like JIRA and Azure DevOps provides details such as the steps to replicate the defect, screenshots, and logs.
Defect Triage: After logging the defect, the development team performs a defect triage. This process involves reviewing the defect and deciding on its severity and priority. For example, the development team reviews the defect reported by the tester and decides that it is a high-priority defect that needs to be fixed immediately.
Defect Assignment: Once the defect is triaged, the development team assigns the defect to a developer. The developer who is assigned the defect will review the details of the defect and start working on fixing it. For example, the development team assigns the defect to a developer who is responsible for the login functionality.
Defect Fixing: The developer starts working on fixing the defect once it is assigned to them. They will review the details of the defect and reproduce it in their development environment to identify the root cause of the issue. Once the root cause is identified, they will develop a fix and implement it. For example, the developer may find that the login screen's code has a bug that is causing the defect, and they will fix the code to resolve the issue.
Defect Verification: After the developer fixes the defect, the tester verifies the fix to ensure that it has resolved the issue. The tester will follow the steps to reproduce the defects that were logged in the defect tracking tool and check if the issue has been resolved. If the issue has been resolved, the tester will mark the defect as closed. For example, the tester will test the login screen again to verify that the defect has been fixed.
When a bug is discovered, it is escalated to different levels with team coordination involving QA, developers, and project managers
New: This is the initial level of the bug's lifecycle. It indicates that the bug has been discovered for the first time and Software tester communicates with the test lead to confirm that it's a valid bug. Once the bug is confirmed from the test lead, the bug has been reported in the bug tracking tool. At this stage, the bug is waiting for the development team to analyze and evaluate it.
Assigned: Once the development team has reviewed the bug report, Project manager will assign it to a developer to fix it. The developer will then work on developing a solution to resolve the issue.
Open: After the bug has been assigned to a developer, it is marked as 'Open'. At this stage, the developer is working on fixing the bug.
Fixed: Once the developer has developed a solution and tested it, the bug is marked as 'Fixed'. This shows that the bug has been resolved, and the fix is ready for testing.
Pending Retest: After the bug has been marked as 'Fixed', it is assigned back to the testing team for retesting. The bug is marked as 'Pending Retest' until the testing team has verified that the fix has resolved the issue.
Retest: During the retesting stage, the testing team will verify that the bug has been fixed and that there are no new bugs introduced. If the bug is still present, it will be sent back to the development team to be fixed again.
Could not reproduce: If a developer is unable to reproduce a bug using the steps provided in the bug report by the QA team, they can mark the bug as 'CNR' (Cannot Reproduce). In such cases, the QA team needs to investigate whether the bug can be reproduced and provide detailed steps for reproducing the bug. The bug can then be assigned back to the developer for fixing.
Need more information: If a developer is unsure about the steps to reproduce a bug provided by the QA team, they can mark it as 'Need more information.' In such cases, the QA team needs to provide detailed steps for reproducing the bug and assign the bug back to the developer for fixing.
Closed: Finally, if the bug is verified as fixed, it is marked as 'Closed'. The bug is considered to be resolved, and the issue is closed.
Reopen: If the QA team is not satisfied with the fix provided by the developer, and the bug is still reproducible, they can mark it as 'Reopen.' This allows the developer to take appropriate action to address the issue.
Rejected/Invalid: If the system is functioning as per specifications and the bug is a result of misinterpretation, the developer or team lead may mark the bug as 'Rejected' or 'Invalid'.
To check our blogs on testing please refer to this : Testing life cycle (STLC) and its phases.
