Skip to main content

Defect/Bug Life Cycle

Bug Life Cycle:
It is a cycle in which a defect goes through different phases during its lifetime

The Journey of a Defect/Bug from its NEW (or Born/Found) state to Close (or END/Fixed) state, so this journey of a cycle is known as ‘BUG LIFE CYCLE’. We can also called it as ‘DEFECT LIFE CYCLE’





1.       New:  When a defect is logged and posted for the first time. It’s state is given as new.
2.       Assigned:  After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned.
3.       Open:  At  this state the developer has started analyzing and working on the defect fix.
4.       Fixed:  When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
5.       Pending retest:  After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.
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.       Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through 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”. This state means that the bug is fixed, tested and approved.
10.   Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“.
11.   Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.
12.   Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
13.   Not a bug:  The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.

Comments

Post a Comment

We appreciate your valuable Suggestions/Feedback

Popular posts from this blog

Key Points of Leading RPA Tools

Key Points of Leading RPA Tools Automation Anywhere(AA) Blue Prism(BP) UI Path Developer friendly tool RPA Term was invented by Blue Prism Extremely User Friendly Offers Front and Back Office Robots It is an Enterprise grade RPA Solution tool Implementation Speed is high Script based, More Programming Skills required Supports only Back Office robots Re Usability is more since various integrations available with different workflows Smart Recorder Option available Code Insertion is difficult and not user friendly Free Community edition (PDF’s, Videos available for FREE) AA Bots can deploy in Physical Front Office machines & Cloud Extreme control over activities (Object Creation, Coding etc.) Con is - No Coding Annual support cost and license cost is higher What is Best RPA Tool...
4 comments
Read more

RPA Implementation Approach

RPA Implementation Approach: 1. Tool Selection o     Based on user requirements, features available in tools, you’ve to select TOOL from mentioned above         2. Process Prioritization o     After successful section of Tool, you’ve to consolidate & prioritize the all processes in current operation. Let’s start automating lowest first and most important to next
Post a Comment
Read more

Types of Recording

Types of Recording: 4 types of recording modes are available Ø   Basic Ø   Desktop Ø   Web Ø   Citrix 2 ways of Recording Ø   Automatic Ø   Manual Basic – generates a full selector for each activity and no container, the resulted automation is slower than one that uses containers and is suitable for single activities. Desktop – suitable for all types of desktop apps and multiple actions; it is faster than the Basic recorder, and generates a container (with the selector of the top-level window) in which activities are enclosed, and partial selectors for each activity. Web – designed for recording in web apps and browsers (supported: Internet Explorer, Google Chrome), generates containers and uses the Simulate Type/Click input method by default. Citrix – used to record virtualized environments (VNC, virtual machines, Citrix, etc.) or SAP, permits only image, text and keyboard automation, and requires explici...
Post a Comment
Read more