Defect Life Cycle

Introduction:

Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of Application under Test (AUT).

Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that process is standardized.

Defect life cycle, also known as Bug Life cycle. 
The bug has different states in the Life Cycle.  

Bug or Defect Life Cycle

The Different states of a bug can be summarized as follows:

New 
Assigned
Open
     Duplicate
     Rejected
     Deferred - Next Release
     Not a Bug
Fixed
Pending Retest
Retest
     Reopen
Verified
Closed

Description of Various Stages:

1. New: When the bug is posted for the first time, its state will be “NEW”. (That means the bug is not yet approved.)

2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine then he assigns the bug to corresponding developer and the developer team. It's state given as assigned.
                         (Here TE has posted a bug, TL approved that the bug is genuine)

3. Open: At this state the developer has started analyzing and working on that defect to fix.

4. Fixed: When developer makes necessary code changes and verifies that changes then he/she can make bug status as 'Fixed' and the bug is passed to the testing team.
                  (It specifies that the bug has been fixed and is released to testing team)

5. Pending retest: Once the defect is fixed the developer gives particular code for retesting the code to the tester for next round of testing.  Since the testing remains pending from the testers end, the status assigned is 'pending request'.

6. Retest:  At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not.

7. Verified: The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to 'verified'.

8. Reopened: If the bug still exists even after the bug is fixed by developer, the tester changes status to 'Reopened'.  It traverses the life cycle once again.

9. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to 'Closed'. 

That means bug is fixed, tested and approved.
---

10. Duplicate: If the bug is repeated twice or mention the same bug again in that case one bug status is changed to 'Duplicate'.

11. Rejected: Developer rejects the bug, because it is not genuine. Then the state of the bug is changed to 'Rejected'.

12. Deferred: It means the bug is expected to be fixed in next releases, because many factors.  i.e., low priority, lack of time for release or the bug not have major effect on the s/w.

13. Not a bug: The state given as 'Not a bug' if there is no change in the functionality of the application. 
      Ex: If customer asks for some change in the look and feel of the application like change of colour of some text then it is not a bug but just some change in the look of the application.
---

Types of Bugs:

During test execution test engineers are detecting below types of mismatches in build.

1. User interface bugs (Low Severity)
    Ex: 1. spelling mistake (High priority)

2. Improper right alignment (Low priority)

3. Error handling bugs (Medium Severity)
    Ex: 1. doesn’t return error message to prevent wrong operation. (High priority)

4. Complex meaning in error message (Low priority)

5. Input Domain bugs (Medium Severity)
    Ex: 1. Does not taking valid type values (High priority)

6. Allows invalid type also (Low priority)

7. Calculations bugs (High Severity)
    Ex: 1. Dependent o/p is wrong (High priority)

8. Final o/p is wrong (High priority)

9. H/W related bugs (High Severity)
    Ex: 1. Device is not responding to application (High Priority)

10. Returns wrong o/p by device (Low priority)

11. Load Condition Bugs (High Severity)
      Ex: 1. doesn’t allows multiple user (High Priority)

12. Doesn’t allows customer expected (Low priority)

13. Race condition bugs (High Severity) Ex: 1. Deadlocks are hanged.(High priority)

14. Doesn’t run on all customer expected plat forms (Low priority)

15. Version Control Bugs (Medium Severity)
      Ex: 1. Mismatches in between two consecutive builds released from developers.

16. Id – Control Bugs (Medium Severity)
      Ex: Logo missing.
            Wrong logo.

            Ver. No. Missing.

            Wrong Ver. No’s.

            Team members missing.

            Copy right window missing.

17. Source bugs: (Medium Severity)
      Ex: mistakes in Help Documents.

Note: 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.

Note: The bug life cycle may not include all the states that have been shown in above.  The number of states that a defect goes through varies from project to project.
---

Defect Life Cycle Related Topics:

2. What is Bug?
    It Defines Abnormal Behavior of the software.
    The Bug attains different states in the life cycle.

3. When the Defect occurs in the Project?
    When the developer deviate the requirements then bug appears at testing phase in the project.

4. What is Bug density ? 
    The Average no. of bugs testing team found in one module called bug density.

5. What is Application Under Test(AUT)?
---

 Real time bug status document: 

***