[highlight dark=”no”]You should be familiar with the defect lifecycle,[/highlight] in order to clearly understand the bug status, know how to rapidly and properly describe them, write them and close them in the bug-tracking systems.

[highlight dark=”no”]Defect Lifecycle[/highlight] – it’s the stages, through which a defect goes through, from the moment it appears to the time when it is fixed. For easy understanding, a lifecycle is depicted in the form of a scheme, where all statuses and actions that replace these statuses are displayed.

Every stage of working with a bug is called a “Status”. Such a status shows at any stage what should be done with a defect and who is currently working with it. When one of the developers stops working with a defect, the defect status is changed and it goes to another person, who continues working with it.

In most cases, [highlight dark=”no”]the defect lifecycle is directly connected with the management system that has been chosen for working with it.[/highlight] Generally, all statuses and actions are automatically configured in such a bug-tracking system but there are also such systems where you can adjust the defect lifecycle to a certain project if needed.

In a bug-tracking system, an admin can add users that can view and correct the defects, according to their statuses, change their statuses or completely remove them.

Statuses in the defect lifecycle and their description

“New” – a bug is added to a management system for the first time.

“Assigned” – a bug report is assigned to a certain user.

“Open” – a user starts working with a report (analysis and editing).

“Fixed” – a user made necessary adjustments to code and test them by himself/herself. The report gains the “fixed” status and returns to a tester.

“Pending retest” – a developer fixed a bug, delivered a new code for testing.

“Retesting” – a tester checks the code that has been changed by a developer, for the second time, in order to check whether a bug has been fixed.

“Verified” – if a defect has been fixed, a tester gives a bug such a status.

“Reopened” – if a bug appears again, a tester redirects it to a developer. The defect goes through the same stages.

“Closed” – such a status is given by a tester if he/she is sure that a bug has been fixed and it doesn’t appear again.

“Duplicate” – if a bug happens more than one time or there are two defects that appear as a result of the same issue, one of them gains such a status.

“Rejected” – if a developer doesn’t consider the bug as the major one and it doesn’t need to be analyzed and fixed, he/she rejects it.

“Deferred” – we can hope that such a bug will be fixed in other versions. In most cases, a defect gains such status for several reasons: low priority of the bug, lack of time, the bug won’t cause a big failure in software functioning.

“Not a bug” – it is assigned in the case when software functionality won’t be changed. For example, a client desires to change the button size and product color – it’s not a bug but simply the need for making changes to software design.

Defect lifecycle stages

1. A tester finds a bug;

2. A tester adds the bug report to a bug tracking system (the “New” status) and directs it to a developer (the “Assigned” status).

3. A developer analyzes the bug, the ways of its reproduction and gives it one of the statuses, according to the actual results:

• Duplicate – a similar bug has been already added to a bug-tracking system;
• Rejected – the bug shouldn’t be fixed since its influence on a product is minor;
• Deferred – the bug can be fixed in another software version;
• Not a bug – the defect is not a bug, therefore, it doesn’t need to be fixed;
• Open – the defect is being fixed;
• Fixed – the code has been changed and tested by a developer.

4. a tester rechecks the bug (the “Retesting” status).

5. If the bug is already fixed, a tester closes it (the “Verified” status and then – the “Closed” status).

6. If the bug appears again, it’s directed to a developer for fixing (the “Reopen” and the “Assigned” statuses) and goes through every stage of the cycle one more time.

With the help of defect statuses in a bug tracking system, we can create reports that will help us to evaluate the work of both a developer and a tester, while they are providing their software testing services.