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

Brief Overview of RPA

Brief Overview of RPA:     §   In short, it’s a way for machines to replace human workers in regular activities done across the organization.     §   It works on both Front End & Back End applications/operations.     §   BOT provides Virtual automation agents , it acts like MIMIC HUMANS .     §   BOT ’s available in Clouds/Servers     §   BOT is nothing but a configurable software set up, works only on rule-based triggers     §   It automates Non-Value –added works     §   It is a Sub Domain of BPMS (Business Process Management Software)
2 comments
Read more

RPA Life Cycle

RPA Life Cycle: It is similar to software development life cycle with some minor changes. Technically, we called it as ‘ Life Cycle of a Bot’   Analysis:           ·     RPA Cycle begins from ‘ Analysis ’ phase.           ·     In this, Business Team & RPA Strategist/Architect identifies business process to automate           ·     After finalizing feasibility on process, implement plan of work (which includes documentation, Resources count & Time  ...) Development:          ·       Dev. Team starts working on requirements wrt to Environment.          ·       We called this phase as ‘ Bot Development ’          ·       Based on Tool selection , Limited/No coding is required ...
Post a Comment
Read more

Why RPA, Why not Other Tools

Like below there are several features compared to other tools RPA QTP/UFT SELENIUM Commercial Commercial Open Source Less Programming Moderate Programming More Programming License Cost is Less License Cost is More No license cost Free Version No/Minimal additional cost for extra bots Add-Ins Additional cost is very high Free/Paid Add-Ins are available ROI is more ROI is less compare to RPA ROI is more as Open Source Error rate almost to Zero Error rate is moderate Error rate is moderate Customer Satisfaction is high Customer Satisfaction is Moderate Customer Satisfaction is Moderate User Friendly User Friendly Complex 24*7 support 24*7 support No Support
1 comment
Read more