In this post, we will be discussing the defect\/bug life cycle. During development till testing, every bug which has been detected passes through a set of processes, called a bug life cycle.<\/p>\n

\n<\/ins>\n<\/div>\n

\u00a0As we all know that the development process follows the software development life cycle. But the development process is not easy and not always runs smoothly. <\/p>\n

During the development phase, when the product is under development, bugs or defects arise. So, these bugs are identified and corrected all the way in the development life cycle and the testing life cycle to deliver a bug-free and quality product.<\/p>\n<\/div>\n

What is a bug\/defect?<\/b><\/span><\/h3>\n
As we have already discussed, a bug or defect is a deviation of the flow of an application from its expected behavior as per the requirement specification. So, it is one of a tester\u2019s important responsibility to find as many defects as possible to ensure the delivery of a quality product.<\/p>\n
Now, Let\u2019s understand about the defect\/ bug life cycle in detail along with the phases of the life cycle.<\/p>\n
Bug or Defect Life Cycle<\/b><\/span><\/h3>\n
Bug life cycle mainly refers to the entire phases of detecting a new bug\/defect by a tester to closing that bug by the tester.<\/p>\n
The journey of bug cycle varies from organization to organization, and from project to project as development processes, and platforms as well as the testing tools and environments also differ depending upon the organization, and project.<\/p>\n
The below diagram shows the workflow of bug life cycle:<\/strong><\/p>\n
<\/strong><\/p>\n
$\"\"$ <\/p>\n
<\/p>\n
Phases of the bug life cycle<\/strong><\/h3>\n
NEW <\/u><\/b><\/h5>\n
It is the first stage of bug life cycle where a new defect\/ bug is detected by the tester. The tester prepares a defect documentation and share it with the development team so that the developers can go through it and fix the bug accordingly. If the bug is non reproducible, it is the role of the tester to share the screenshot and time-stamps of the bug. When the testers detect the bug, the bug goes into \u2018NEW<\/strong><\/em>\u2019 state.<\/p>\n
ASSIGNED<\/b><\/h5>\n
Defects that are in status \u2018NEW will be approved and the defect is assigned to the development team so that they can work on that defect and resolve it. When the defect is assigned to the development team, the bug is in \u2018ASSIGNED<\/strong><\/em>\u2019 state.<\/p>\n
OPEN<\/b><\/h5>\n
In the \u2018ASSIGNED\u2019 state, the bug is assigned to the development team. When the development team starts working and analyzing the bug, they change the state to \u2018OPEN<\/strong><\/em>\u2019.<\/p>\n
\u00a0If the developer feels that the defect is not appropriate, then the developer can assign the states to DUPLICATE, DEFERRED, REJECTED, <\/b>and <\/em>NOT A BUG<\/em>,\u00a0<\/b>based upon the specific reasons.<\/p>\n
Let\u2019s discuss these states of bugs which developer can assign:<\/p>\n
\n
Rejected<\/b>: If the defect is not considered as a genuine defect by the developer then it is marked as \u2018Rejected\u2019 by the developer.<\/li>\n
Duplicate<\/b>: If the developer finds the defect as same as any other defect or if the concept of the defect matches any other defect then the status of the defect is changed to \u2018Duplicate\u2019 by the developer.<\/li>\n
Deferred<\/b>: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as \u2018Deferred\u2019.<\/li>\n
Not a Bug<\/b>: If the defect does not have an impact on the functionality of the application then the status of the defect gets changed to \u2018Not a Bug\u2019.<\/li>\n<\/ul>\n
FIXED<\/b><\/h5>\n
After the bug is fixed and the necessary changes are done, the developer team marks the bug into the \u2018FIXED<\/strong><\/em>\u2019 state.<\/p>\n
PENDING RETEST\u00a0<\/b><\/h5>\n
Once the defect is fixed the developer gives a particular code for retesting the code to the tester. As the code is pending for retesting, hence the status is assigned by the testers as \u2018PENDING RETEST<\/strong><\/em>\u2019.<\/p>\n
RETEST<\/b> <\/u><\/b><\/h5>\n
Now, when the tester starts working on retesting the defect to check whether the development team has correctly fixed the bug or not, he assigns the state of the bug as \u2018RETEST<\/strong><\/em>\u2019. <\/u><\/b><\/p>\n
<\/u><\/b><\/p>\n
REOPEN<\/b> <\/u><\/b><\/h5>\n
If the bug persists after the development team has fixed the defect, then the tester reopens the bug. The bug then has to go to the entire life cycle again and the tester changes the state to \u2018REOPEN<\/strong><\/em>\u2019.<\/p>\n
VERIFIED<\/b><\/h5>\n
If the tester confirms that the bug is fixed after he receives the bug fix from the development team and done with the retesting, then the tester changes the state of the bug to the \u2018VERIFIED<\/strong><\/em>\u2019 state.<\/p>\n
CLOSED<\/b> <\/u><\/b><\/h5>\n
it is the final state of the bug life cycle. When the tester confirms that the bug is fixed, and retesting is done, and no such bug exist anymore, then the tester changes the state of the bug as the \u2018CLOSED<\/strong><\/em>\u2019 state.<\/p>\n
Let\u2019s look into the detailed version of the bug life cycle.<\/p>\n
Detailed Bug Life Cycle Explained<\/b><\/h3>\n
<\/b><\/p>\n
$\"\"$ <\/b><\/p>\n
<\/b><\/p>\n<\/div>\n
\n
1. Tester finds the defect.<\/p>\n
2. Status assigned to defect- New<\/strong><\/em><\/p>\n
3. A defect is forwarded to Project Manager for analyze.<\/p>\n
4. Project Manager decides whether a defect is valid<\/strong><\/em>.<\/p>\n
5. Here the defect is not valid- a status is given “Rejected<\/strong><\/em>.”<\/p>\n
6. So, the project manager assigns a status rejected<\/strong>. If the defect is not rejected, then the next step is to check whether it is in scope.
Suppose we have another function- email functionality for the same application, and you find a problem with that.
But it is not a part of the current release when such defects are assigned as a postponed <\/strong>or deferred <\/strong>status.<\/p>\n
7. Next, the manager verifies whether a similar defect was raised earlier. If yes defect is assigned a status duplicate<\/strong>.<\/p>\n
8. If no the defect is assigned to the developer who starts fixing the code. During this stage, the defect is assigned a status in- progress<\/strong>.<\/p>\n
9. Once the code is fixed. A defect is assigned a status fixed<\/strong>.<\/p>\n
10. Next, the tester will re-test the code. In case, the Test Case passes the defect is closed<\/strong>. If the test cases fail again, the defect is re-opened<\/strong> and assigned to the developer.<\/p>\n
11. Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax order that was fixed and assigned a status closed<\/strong>.
During the second upgrade release the same defect again re-surfaced. In such cases, a closed defect will be re-opened<\/strong>.<\/p>\n<\/div>\n
\n
That\u2019s all to the bug life cycle. Now let\u2019s look into the advantages and difficulties of following the bug life cycle.<\/p>\n
Advantages of following a Bug Life Cycle<\/b><\/span><\/h3>\n
\n
Better service ad customer satisfaction.<\/li>\n
Deliver high quality product.<\/li>\n
Better communication, teamwork and connectivity.<\/li>\n
Detecting issues earlier and understanding defect trends.<\/li>\n
Improve Return on Investment (ROI) by reducing the cost of development.<\/li>\n<\/ul>\n
Challenges<\/b><\/span><\/h3>\n
\n
No control on test environment.<\/li>\n
Variations of the bug life cycle.<\/li>\n<\/ul>\n
Let\u2019s summarize what we have learned so far:<\/strong><\/p>\n
Summary<\/b><\/h3>\n
\n
What is bug<\/li>\n
Workflow of bug<\/li>\n
States of bug<\/li>\n
Detailed understanding of the bug life cycle<\/li>\n
Advantages and difficulties of a bug<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n<\/section>\n
<\/body><\/html><\/p>\n","protected":false},"excerpt":{"rendered":"
Table of Contents What is a bug\/defect? Bug or Defect Life Cycle Phases of the bug life cycle NEW ASSIGNED OPEN FIXED PENDING RETEST\u00a0 RETEST REOPEN VERIFIED CLOSED Detailed Bug Life Cycle Explained Advantages of following a Bug Life Cycle Challenges Summary In this post, we will be discussing the defect\/bug life cycle. During development […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-739","post","type-post","status-publish","format-standard","hentry","category-software-testing","post-wrapper","thrv_wrapper"],"_links":{"self":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/739","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=739"}],"version-history":[{"count":0,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/739\/revisions"}],"wp:attachment":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=739"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=739"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=739"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}