Bug_LifeCycle

Bug LifeCycle:

    Defect: A defect is an error or a bug in the application which is created.

    A programmer while designing and building the software can make mistakes or errors. These mistakes or errors mean that these are flows in the software. These are called defects.

The bug life cycle is also called a Defect life cycle.

The phases of the bug life cycle:

New                

↓                 

↱￣￣￣ Assigned ￣￣￣↱ Rejected

             Re-opened          ↓                      ↳ Deferred                   

                       Fixed                  ↳ Duplicate

↓                

Re-tested            

↓                

Verified               

↓               

Close               

Case 1: (Re-Solved)

New

↓

Active

↓

Re-Solved

↓

Closed

• ("Jira=TFS", New=Proposed, Active = Acknowledged)
• New: The Bug was found and it was assigned to the developer.
• Active: Once the developer accepted the bug and then they start working on that bug.
• Re-Solve: Once the developer fixed that bug and assigns it back to the QA. whoever raises that bug.
• Closed: The QA will verify that bug if everything is fine they make it as close.

Case 2: (Duplicate)

New

↓

Active

↓

Duplicate

↓

Closed

• If two QA's raise the same bug they will take the 1st QA bug and they identified the 2nd QA bug as a duplicate.
• 2nd QA will check that bug, if it's the same, then they close the bug. (Also 2nd QA wants to write the reason why we close that bug. Example reason like: "There is one more same bug raised with Bug ID:----, hence close the bug").

Case 3: (Deferred)

New

↓

Active

↓

Deferred

• Whenever we have a very tight timeline and the bug is not necessary for that particular release during that scenario they mark the particular bug as 'Deferred' and they push that to the backlog.
• If there are a lot of bugs in a deadly timeline(Lack of time) then they call the client and decide which bugs are the priority and which bugs are the non-priority.
• Priority Bugs will be going fixed.
• Non-priority bugs will be in the deferred state and they will push this to the next backlog.

Case 4: (Rejected)

New

↓

Active

↓

Rejected

↓

Closed

• The developer can't able to replicate the bug (not fix it).
• If the developer feels that the defect is not a genuine defect then it changes the status to Rejected.
• If the bug which was assigned to the developer is not an authentic one, then the developer mentions the status of the bug as 'Rejected' with proper reasons.

Case 5: (Re-open)

New

↓

            Active        ↰

                             ↓           Re-open

            Re-Solve    ⤴

↓

Closed

• If the bug persists even after the developer has fixed the bug, the tester changes the status to 'reopened'. Once again the bug goes through the life cycle.

        (If the bug still appears after the developer has fixed then they re-open that bug and again assign it back to the developer)

Test Close:

• After Re-Solved the bug, don't close the user stories we need to assign them back to BA Name. (like, My testing is completed you please continue your BA Testing and add a tag: ready for release)
• Sometimes After release, the customer/client will raise the bugs -> After re-solved the bug -> we assign it back to the client -> then the client will close the bug.