Before moving on to different life cycle states, first understand the difference between a mistake, bug & a defect.
Defect Life Cycle
Everything has a life cycle – it’s the law of nature, a series of changes in form that an organism undergoes, returning to the starting state. Birth >> Infancy >> Childhood >> Teenage >> Adult >> Mature >> Old age >> Dead end. A ‘Defect’ in Software Testing also follows a pre-defined stage transitions from its identification till its closure. In Software Testing terms, we call it as ‘Defect Status transition’ or a ‘Defect Life cycle’!
Note: Generally a Defect Management tool (HP ALM, JIRA, Bugzilla, etc.) is used for capturing and maintaining defects throughout their life cycle.
Software development and testing go hand-in-hand. As developing a software with bugs is not fruitful, similarly just identifying the defects is not fruitful either, unless the defects are resolved & retested. Therefore developers, testers and business team form an integral part of the defect life cycle process. As we will see multiple participants are involved during a defect’s status transition from ‘New’ until it is ‘Closed’. Let’s jump to the different ‘statuses‘ that a ‘defect’ undergoes during its ‘life cycle’.
Note: Defect Life cycle varies from organization to organization and is governed by the software testing process the organization or project follows and/or the Defect tracking tool being used. Let’s look at the industry-standard. Please note that the change in status responsibility is mentioned in the brackets.
It’s self-explanatory. Say you identify a defect in the Application-under-test (AUT). What’s next? Yeah! Logging it in a defect management tool. By default, whenever you log a defect its status is ‘NEW’. Mind you, it doesn’t mean it’s a valid defect and will be fixed – the analysis is not yet done!
Assigned (Test / Development Lead >> Developer)
Development teams vary in sizes. Some teams might have 10 people and others might have 50+ resources. How will a developer come to know that he/she has to fix this particular defect? Nah! Sending email for every new defect is not feasible. What if you encounter 100+ defects in an application? The way-out: Both development team members and Test team have access to the defect management system. As a Test Lead or a Development Lead whenever you notice a ‘New’ defect in the system the next step is to analyze the defect for its correctness. If valid, assign it to a particular developer (‘Assigned to’ field) and change the status to ‘Assigned’!
a. Deferred (Team Lead, Business Team)
Deferred as in delayed or postponed. After initial analysis it is observed that a particular defect will not be fixed as of now, i.e. in this release. It will be fixed in some future release. Therefore, the Lead will change its status to ‘Deferred’ and it will not be picked up as part of this release but some future release. And why do you think a defect will be deferred? There are multiple factors and there can be multiple reasons – very low priority, lack of time, not part of current requirement, technical dependencies, etc. Generally it’s a standard practice to get sign-off from the business team before marking a defect as ‘Deferred’. After all, they know the best about the business impact.
b. Rejected (Test / Development Lead)
After all ‘To err is human’. Even a tester can make mistakes. What if you used a wrong test data? What if your application understanding is wrong? Didn’t understand the requirement? Defect is already logged by some other tester? The functionality is out-of-scope? It is not a requirement? Wrong observation? Yeah! What if you as a tester have raised an invalid defect? Obviously it will be rejected. If after analysis it is observed that this is NOT a defect, then Lead will change the status to ‘Rejected’ mentioning the details in the comment section.
Once a defect is assigned to a particular developer – he/she starts working on the defect fix and changes the status to ‘Open’. Working as in analyzing the defect, investigating its root cause and rectifying the code.
Once the code changes are done & verified in the development environment – the assigned-to developer changes the status to ‘Fixed’. What’s next? The fixed code needs to be deployed in the Test environment post which it will be verified by the Test team.
Ready for Test (Developer >> Tester)
What’s the difference from ‘Fixed’? The Environment. Once the rectified code is deployed in the Test environment – it is available for the Test team to verify, i.e. retest. Post deployment, the developer changes the status to ‘Ready for Test’ and assign it back to the tester (who logged it). Tester verifies that the fixed code is working fine and the defect is no more reproducible.
If the rectified code is working as expected, i.e. the defect is no more reproducible – the tester changes the status to ‘Closed’. It means that the defect is fixed & retested successfully and is no longer reproducible. Happy Ending!
a. Reopen (Tester >> Developer)
Say the developer was an idiot 🙂 – during retest you find that the defect is still present even after the fix. What to do now? Simple, just change the status to ‘Reopen’ and assign it back to the developer. The lifecycle starts again from status 3.
As multiple people are involved in the overall defect management process – it is imperative to add relevant ‘Comments’ at each status transition. For other Defect Management guidelines, we will have a separate post.