Defect is an unexpected behaviour (or) unexpected flow of the software application against to requirement document. A Defect can be an error/bug which includes: Functional errors, Communication errors, Syntactic errors etc. A Defect has its own life cycle in software testing from the day it found to till closing.
In this blog, I have discussed what are all the phases a Defect would go through during its life cycle and who are the Key Players.
Consider the Defect life cycle as shown in picture:
Following are the phases that a defect will go through during its life cycle:
- New
- Assigned
- Open
- Deferred
- Duplicate
- Rejected
- Could Not Reproduce
- Fixed/Resolved
- Re-Opened
- Closed
Before going to defect life cycle discussion, let us first get to know the Key Players in defect life cycle:
- Defect Owner
- QA Lead
- Defect Tracking Tool
- Defect Group
è Defect Owner: The one who identifies the defect and logs the defect details in defect tracking tool with all the necessary information required like: Subject, Description, Module, Priority, Severity, Type of Defect, Reproduction Steps etc. Usually this task is done by QA team and sometimes End users.
è QA Lead: The responsibility of this role is to review the Defects and checks if the description provided is specific and can be reproduced based on the steps provided. If the information provided seems to be not satisfying, he/she may assign back to Defect Owner to recheck the information provided.
è Defect Tracking Tool: When a defect is identified, the defect owner logs the details into Defect tracking tool which helps in reporting. Defect Tracking Tool can be project/company specific. Eg: Jira, TFS, BugZilla etc.
è Defect Group: It specifies the group of people who can watch the activities of defect. Usually this group contains: QA Team, Development Team, QA Manager and Project Manager.
Now, let’s see how these Key players are involved in Defect Life Cycle:
è When a defect is first identified by the defect owner it is logged into defect tracking tool. This is called “NEW” phase of the Defect. QA lead will review the Defect that is logged and assign to Development Team (Development Lead) with “NEW” as status.
è The development lead (or) project manager will consider the defect and changes the state to “ASSIGNED” and assign it to the respective developer.
The development lead / Manager can reject the Defect with status “REJECTED” if the defect is not a valid defect and assigns back to QA team with proper explanation mentioned in defect description. The QA team further may reopen/close the defect based on the explanation provided.
The development team can change the defect status to “Could Not Reproduce” when failed to reproduce the defect with steps provided in the description box and assign back to QA team seeking for more information to reproduce. The QA team will further verify and may add detailed steps to reproduce the defect. QA team should attach the screenshots or submit all possible scenarios to reproduce the defect.
If the defect has no major impact on the current release and same can be fixed in next release (or) if the defect is not important to fix immediately then the development lead / Manager can make the status to “DEFERRED”.
If the logged defect is found to be duplicate then the status of defect is changed to “DUPLICATE” and assigned back to QA team with primary defect ID referencing in the comment section. The QA team will review the defect act accordingly (close / reopen).
The developer will change the defect status to “OPEN” and start working on it. Once the defect is fixed, the status of defect is changed to “RESOLVED” and will assign back to QA to retest the defect fix.
The QA will re-test the defect and change the state from RESOLVED to “CLOSED” if it is fixed and the application flow is working as expected else status is changed to “REOPEN” if it is re-producible and assigned back to respective developer with the comments mentioned why it is reopened.
To know more about Testing, Subscribe to our Newsletters.
Happy Defect Reporting 😊