Defect / Bug Life Cycle

What is a Defect/Bug?

Defect is a flaw in a software system,such software system when executed results in failure. So we can say that Failure occurs because of the defect in a software system.

Different Types of Defects:

Ø  User interface defects

Ø  Code defects

Ø  Test data related defects/Test script error

Ø  Error handling defects

Ø  User education issue

Ø  Documentation issue

Ø  Environment issue 

Testing is done to find defects in the application. Once the tester comes up with a defect it goes to the developer to fix it. The tester has to keep a track of the defects until it is fixed. In this process the defect/bug is given different status depending on whether is it fixed or not. The Bug Life Cycle (Keeps track of the bug) tells about the different status it goes through or rather it is used to track the defects during testing.

Roles:

TE:  Test Engineer

TL:  Team Leader

DEV: Developer

Different Scenarios For Bug Status:

1. REJECTED:

 Description:

1) When the TE identifies the defect for the first time, he gives it a status NEW

2) Now the defect goes to the TL for his approval.

3) If he doesn’t find it as a defect he gives status is REJECTED.

2. DIFFERED:

 Description:    

    

1) When the TE identifies the defect for the first time, he gives it a status NEW

2) Now the defect goes to the TL for his approval.

3) If the defect is approved by the TL he gives it a status OPEN

4) The defect goes to the developer for him to fix it.

5) If the developer finds that the defect is caused due to undeveloped module, then he gives this bug a status DIFFERED

If the developer wants to fix the bug in the later stage, then he gives the bug status is DIFFERED

3. CLOSED:        

Description:

1) When the TE identifies the defect for the first time, he gives it a status NEW

2) Now the defect goes to the TL for his approval.

3) If the defect is approved by the TL he gives it a status OPEN

4) The defect goes to the developer for him to fix it.

5) The developer fixes the bug and gives it a status FIXED

6) The tester retests (process) to find if the defect is fixed or not. If he doesn’t find the     same defect, TE gives status is CLOSED.

4. RETEST:

Description:

1) When the TE identifies the defect for the first time, he gives it a status NEW

2) Now the defect goes to the TL for his approval.

3) If the defect is approved by the TL he gives it a status OPEN

4) The defect goes to the developer for him to fix it.

5) If the developer feels that there is nothing wrong with the code, he asks the tester to retest and gives the bug a status RETEST

6) If the tester agrees with the developer and finds no defect this time he gives a status is CLOSED.

5. REOPEN:

Description:

1) When the TE identifies the defect for the first time, he gives it a status NEW

2) Now the defect goes to the TL for his approval.

3) If the defect is approved by the TL he gives it a status OPEN

4) The defect goes to the developer for him to fix it.

5) The developer fixes the bug and gives it a status FIXED

6) The tester retests (process) to find if the defect is fixed or not. If he still finds the defect he gives the status REOPEN

7) The developer fixes the code (bug) and gives it the status FIXED

8) Now the tester retests (process) to find if the defect is fixed or not. If he doesn’t find the same defect, TE gives status is CLOSED

6. REOPEN & RETEST:

Description:

1) When the TE identifies the defect he gives it a status NEW

2) Now the defect goes to the TL for his approval.

3) If the defect is approved by the TL he gives it a status OPEN

4) The defect goes to the developer for him to fix it

5) The developer fixes the bug and gives it a status FIXED

6) The tester retests (process) to find if the defect is fixed or not. If he still finds the defect he gives the status REOPEN

7) If the developer feels that there is nothing wrong with the code, he asks the tester to retest and gives the bug status RETEST 

8) If the tester agrees with the developer and finds no defect this time he gives a status CLOSED

7. FIXED or REJECTED:  

Description:

1) When the TE identifies the defect for the first time, he gives it a status NEW

2) Now the defect goes to the TL for his approval.

3) If the defect is approved by the TL he gives it a status OPEN

4) The defect goes to the developer for him to fix it.

5) The developer fixes the bug and gives it a status FIXED

6) Now the tester retests (process) to find if the defect is fixed or not. If he still finds the defect he gives the status REOPEN

7) If the developer feels that there is nothing wrong with the code, he asks the tester to retest and gives the bug a status RETEST

8) After retesting if the tester finds that the defect is still present he gives the status REOPEN

9) Here the status REOPEN & RETEST continues between the tester and developer, if this cycle continues for more than 3 times this defect is escalated and goes to the higher authorities and a review is conducted.

10) The higher authorities decide whether the defect should be FIXED or REJECTED

How to post a Defect/Bug?

Bug’s are posted with the help of tools, these tools known as Bug Tracking Tools, customer designed tools, built specific for company’s bug format, accepts the details of the issue from the testers as follows.

1.    Bug ID (Tool generates the ID)

2.    Bug Description

3.    Step’s to reproduce the bug

4.    Hard ware & software environment

5.    Status (New, Re-open……)

6.    Version ID of the build

7.    Assigned to

8.    Severity

9.    Priority

10. Tester Name & Date of execution

Test engineers fill the above fields in the tool, acts as a central repository and tracks the entire bug life cycle.

Types of Bug Tracking Tools:

l  Bug Tracker

l  Jira

l  Bugzilla

l  Team Track

l  CARS Change Point