BUG LIFE CYCLE 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. DIFFERENT SCENARIOS FOR BUG STATUS 1st Scenario NEW REJECTED (TE) (TL) 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 it a status REJECTED. 2nd Scenario NEW (TE) OPEN (TL) DEFERRED DESCRIPTION: (DEV) 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 DEFFERED If the developer wants to fix the bug in the later stage , then he gives this bug a status DEFFERED 3rd Scenario NEW (TE) OPEN (TL) FIXED (DEV) CLOSED (TE) 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 it a status CLOSED. 4th Scenario NEW (TE) OPEN (TL) RETEST (DEV) CLOSED (TE) 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 CLOSED 5th Scenario NEW (TE) OPEN (TL) FIXED (DEV) REOPEN (TE) FIXED (DEV) CLOSED (TE) 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 it a status CLOSED 6th Scenario NEW (TE) OPEN (TL) FIXED (DEV) REOPEN (TE) RETEST (DEV) CLOSED (TE) 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 a status RETEST 8) If the tester agrees with the developer and finds no defect this time he gives a status CLOSED 7th Scenario NEW (TE) OPEN (TL) FIXED (DEV) REOPEN (TE) RETEST (DEV) REOPEN (TE) FIXED REJECTED (DEV) (TL) 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