Different States of Defect and Workflow
Defect is something that cannot be neglected. In software, defect management is usually the main goal of developers. Keeping track of defects that are found throughout defect lifecycle and to manage and handle defect reports should be done to maintain performance and quality of software. Different tools are used by various organizations and companies that generally conduct software testing.
Basically, only single participant owns the defect report at each state of defect lifecycle and is responsible for performing particular tasks. When these tasks get completed, it will further cause defect reports to go to next state. In next state, defect report is assigned to next owner. When defect report reaches to last state of defect lifecycle, then there might be no owner to whom defect report is needed to be assigned. Main reasons for such situations can be :
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
- Defect has already been fixed in prior state and is already tested. Therefore, defect report is considered to be closed.
- Defect report might be invalid due to which it gets canceled.
- If the defect can not be fixed at present, then defect report might be deferred i.e. defect is postponed to be fixed in the next release.
- If defect is not observed further anymore, then defect report is considered to be non-reproducible i.e. Effort in analyzing and fixing that particular defect is a total waste.
Different States to Manage Defect :
During software testing, if defects are found by testers, then testing team takes action to manage and fix them in three different states. These states are given below :
- Initial State :
Initial state, as name suggests, is basically considered as open state or new state. Before proceeding towards resolution of defect, it is necessary to perform a task i.e. To know completely about defect, its impact on system, ways to resolve it, tools, and resources required to resolve it. In this state, different testers are responsible to perform this task i.e. to collection and gather all necessary and essential information that is required to resolve defects successfully. If the information gathered is incomplete and not correct, then main goal to fix and resolve defects cannot be achieved. Therefore, all gathered information should be correct and complete in each perspective.
- Returned State :
Returned state, as name suggests, is basically considered as rejected state or clarification state. As we discussed information gathering is previous state that if defect report created by testers is not correct or incomplete, then resolution of defects cannot be possible. In this state, developers that receive defect reports will reject the report if defect report is not correct or information given is not enough to know about defect and resolve it. Then developers further ask creator of defect reports to give more information and make required changes in defect reports. It is up to the testers or creators that they can either provide additional information and make required changes or accept rejection of report.
- Confirmed State :
Confirmed state, as name suggests, is basically considered as verified state or resolved state. In this test, testers basically perform a confirmation test simply to ensure that doe’s defect is resolved successfully or not. From this conformation test, tester would know that defect is resolved or not. If defect is resolved completely, then tester will close defect report. If defect is not resolved, then tester reopened defect and reassigned defect report to previous owner who will then work on necessary things required to fix the defect.