Software Defect Life Cycle

A defect, in simple language, is a flaw in a system i.e., a system is not working as it should. Defects are also called bugs or faults.

In case of software, when the software code has been built, it is executed and then any defects may cause the system to fail to do what it should do (or do something it shouldn't), causing a failure. However, not all defects result in failures. Some defects stay in system as dormant, and we may never catch them as the conditions for them to occur probably do not occur in the real time environment.

In a typical project, a defect or bug gets identified and then logged in a defect/test management tool by the software tester. But What happens after the defect is logged? Defects should be tracked from logging till closure for any project’s success. Defects usually follow a lifecycle from logging till closure.

All defects move through a series of clearly identified states after being reported. Some of these state transitions occur when a member of the project team completes some assigned tasks related to defect(s). Some of these state transitions occur when the project team decides not to repair a defect during this project, leading to the deferral of a defect. Some of these state transitions occur when the defect description is poorly written or describes behavior which is correct, leading to its rejection.

• When the bug or defect is reported, it is in New status. In general, it moves to an Open status post review. Review step depends on level of formality adopted in a project.
• Once the defect is reported, and if the information is incomplete or incomprehensive or the defect cannot be reproduced by the given details, the defect might be rejected outright by the development team. In this case, the status of the defect is “Rejected”. The rejected status might be accompanied by a detailed reason of rejection within the status. Example - “Rejected - Cannot Reproduce” or “Rejected - Need More Information”.
• Once the defect is rejected, it is assigned back to test team for closure. However, test team may agree or not agree with rejection. They can try replicating again if the rejection is due to reason of “not able to replicate”.
• If more information is required, they can update and assign back to development team.
• If the rejection is due to bad data, test team can retest with valid data and see if the defect is still replicable and assign to development team if replicable or close if not replicable with correct data.
• If the rejection is due to reason “Working as designed”, QA Tester should confirm the requirement (or if there has been a change request on the requirement). If the requirement is ambiguous, defect can be further discussed with BA or PO.
• If the rejection is due to a duplicate defect which is existing, tester should validate the original defect and if found similar, duplicate should be closed. 
• Tester and Developer should also make sure that root cause of defect is appropriately updated in the tool. This will help in deriving metrics in the project.

• If the defect is identified as valid and must be fixed, it is assigned to the developer. In this scenario, status is “Assigned”.
• Another possibility could be that defect is valid, but as per business, this can wait until further releases and it is not a priority for current release. In such a scenario, the defect status will be marked as “Deferred”.
• Once the developer is assigned the defect, he/she assesses it and puts the status as “Work in Progress” implying it is being worked upon in current cycle/sprint.
• Once the developer has worked upon the defect, the status is changed to “Fixed”.
  • The developer should update the root cause of defect in the test management tool and as a best practice mention the component changed to fix the defect.
  • Root cause is helpful for metrics and changed component helps if a similar defect is identified at a later stage.
• Once the defect is fixed, it is assigned back to testing team in a status called “Ready for test”
• Once assigned to testing team, the team retests the defect i.e. they do a confirmation test. Retest can have either of two outcomes – Retest Passed or Retest Failed.
• In case when retest of the fixed defect is passed, we can go ahead and “Close” the defect. No further action is required on it.
• If the retest fails, the defect status goes to “Reopened”. If the defect is reopened, it goes back to development team and is put in “Assigned” status again and the above steps are repeated.

Defect Severity and Priority:

Severity of the bug defines the impact the bug has on application functionality. Severity of the bug is defined by tester/QA team who is working on the application. Depending on how much of a threat the bug can pose to the software, bug severity can be divided into below categories:

• Low: Bug won’t result in any noticeable breakdown of the system
• Minor: Results in some unexpected or undesired behavior, but not enough to disrupt system function
• Major: Bug capable of collapsing large parts of the system
• Critical or Blocker: Bug capable of triggering complete system shutdown.

Priority of the bug defines how soon a bug should be fixed. Priority is defined by BA/Product Owner of the application. In many projects, Tester puts the priority in tool and BA/PO decides if he/she is OK with it or needs to change it based on business needs. Levels of bug priority:

• Low: Bug can be fixed later/ if no High or Medium defects are open.
• Medium: Bug can be fixed in the normal course of development and testing.
• High: Bug must be resolved at the earliest as it affects the system adversely and renders it unusable until it is resolved.

Below points need to be taken care when a defect is logged and/or transitioned to a different state.

• Defect should have complete information provided to replicate the issue with proof of the issue in form of screenshots, logs etc.
• To have minimal defect rejection rate, tester should try and replicate the defect on multiple systems especially for web apps.
• In case of web apps, browser type and version should be mentioned in defect description.
• The defect owner is responsible for transitioning the defect into allowed states.
• Defect severity and priority should be appropriately defined.
• The language of the defect should remain neutral and professional.

Please note, all these statuses are generic in nature and may vary with the tool used and are often customizable. Most defect tracking tools support and enforce the life cycle and life cycle rules. They also allow to customize the life cycle rules based on project needs. While a good defect tracking tool is must to log, manage defects, the actual defect workflow should be monitored and supported by project and company management.