There’s no such thing in this world that is perfect either a commodity or a person. Everything is imperfect in its way. When it comes to software products, forget that even the word “perfect” lies in the dictionary. It’s a harsh reality that software products are full of defects and errors, which need to be fixed or resolved before the product goes live. No matter how many efforts or energies organizations invest in ensuring that their developed software products are free of errors, still, chances of occurrence of some little errors are present. Before the situation gets worse, and the little errors become the reason for massive destruction for organizations, special measures are instilled to make the product maximum free of glitches. For this purpose, many organizations implemented the use of some defect tracking tools and some organizations referred to the independent software testing companies for their expert services.
When an organization plans to put in efforts to avoid software defects, they have to go through a complete defect life-cycle. But what is the defect life-cycle?
Just like software goes from a variety of stages in a software development life-cycle, software defects undergo multiple stages from hunting or tracking to fixing or rectification. The defect life cycle can vary from organization to organization and also from project to project based on several factors like organization policy, software development model used (like Agile, Iterative), project timelines, team structure, etc. Many organizations embrace a simple and easy life-cycle while other organizations may adopt extensive defective life-cycle.
Below in this article, we will take you a ride of various defect life-cycle stages but some of these stages may not be present in the simple defect life-cycle. So let’s get started;
The new state - This is the state when a defect is spotted or found. This the first stage of the software defect life-cycle. Whenever a defect is found it usually falls under this state and then in the later stages preventive measures are taken to fix the defects.
Assigned State - The word assigned itself suggests that once a defect or error is encountered or detected, it is the decision to whom it may be passed to get it fixed timely. For this purpose test manager is responsible to circulate the defect to the developer who he feels can work better on its fixture.
Opening state - In this stage, the developer starts the process of analyzing the defect and works on fixing it, if required. If the developer feels that the defect is not appropriate then it may get transferred to any of the below four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon the specific reason.
And these four stages are;
Rejected: If the defect is not considered as a genuine defect by the developer then it is marked as ‘Rejected’ by the developer.
Duplicate: If the developer who is working on the particular defect’s fixture finds or detects that the same defect is also detected twice or thrice or if the concept of the defect matches any other defect then the developer marks that particular defect as “duplicated” or “repeated”.
Deferred: A developer has the authority to mark a bug or defect as deferred if he/she finds that fixing such defect is not on the high priority list of the testing project and can be fixed later in the software testing life-cycle.
Not a Bug: If the developer finds that the particular bug/defect has no diverse effect over the product functionality or operations then the developer can mark that defect as “Not a Bug”.
Fixture stage - When the developer comes up with a potential solution to solve the particular bug/defect then he/she marks it as “Fixed bugs”.
Pending Retest - After fixing the defect, the developer assigns the defect to the tester for retesting the defect at their end, and till the tester works on retesting the defect, the state of the defect remains in ‘Pending Retest’.
Reopen - If the testing team detects that even after fixture reports of bugs there still lies some issues in the particular defects, then the test manager assigns the same defect with issues to the developer again to fix it potentially. And that is the time when the status of particular defect changes to “Reopen”.
Verified - If the testing team detects no issue in the defect then the particular defect is said to be “verified”
Closed - When the defect does not exist any longer then the tester changes the status of the defect to ‘Closed’.
As a Senior Marketing Consultant at Kualitatem, Ray Parker loves to write tech-related news, articles, specifically quality assurance and information security. Apart from his techie appearance, he enjoys soccer, reading mysteries, and spending long hours working over at the New York office.