JIRA Bug Life Cycle
JIRA bug life cycle is also known as a defect life cycle. The bug life cycle consists of a set of states that a bug goes through. The number of states that the bug goes through varies from project to project. We can define the bug as an error, flaw or we can say that when the actual output does not match with the expected output, it is known as bug or defect. Both the terms, i.e., bug and defect are commonly used but the most popular is a bug. A bug can be generated at any stage of the SDLC(Software Development Life Cycle), it could exist in requirements gathering, designing phase where SRS document is designed, development phase, testing phase or user acceptance testing done by the end-user at the time of using the application.
A bug has its life cycle from the point when the bug is logged in to the point the bug is closed. Bug undergoes the following states:
During the time of the testing phase, the bug or defect is identified by the tester and it is logged in to the bug tracking tool such as Jira, Bugzilla, etc. The bug which is detected by the tester will be posted for the first time in a bug tracking tool. This status is assigned as a New status.
Bug with New status is assigned to the software developers and they will look into the bug to check whether the bug is valid or invalid. If the bug is invalid then they change the status to invalid. If the bug is valid then the status is changed to assigned then the software developers start working on the defect to get fixed.
When the bug is assigned to the software developers then they start analyzing on it and works on the defect fix. The bug or defect can be opened in three stages:
If the defect is repeated twice or the defect corresponds to the same concept of the previous bug, then it changes the status to Duplicate.
If the developer feels that the defect is not a genuine defect, then it changes the status to Rejected.
If the bug is not of higher priority and can be solved in the next release, then the status changes to Deferred. The deferred state is also known as postpone state.
When a developer makes a necessary code changes and verifies the change, then he/she can make the bug status as fixed. When the bug is fixed by the developers then the status is changed to either Reopened or Verified.
Once the bug is fixed by the software developers then it is assigned back to the testing team to check whether the bug has been fixed or not.
If the bug persists even after the developer has fixed the bug, then tester changes the status to Reopen and once again bug goes through the whole bug life cycle.
The tester retests the bug after it got fixed by the developer if no bug found then it changes the status to Verified.
If the bug is no longer exists, then it changes the status to Closed.
Participants of Bug life cycle
- Bug Reporter
The person who identifies the bug is known as Bug Reporter. Bug reporter validates the bug and enters all the bug related details into the bug tracking tool such as correct subject, bug priority, application component, test environment, bug assignee, bug description. When required, the tester needs to send the attached screenshot to clarify the bug details.
- Bug tracking tool
A bug can be logged in to the bug tracking tool and bug tracking tool can be Jira, Bugzilla, Assembla, etc.
- Bug Group
Bug Group is a group of people who can see the bug details. Bug Group can include tester or end user who reported the bug, the developers to whom the bug is assigned, project manager, QA manager.
- Bug Owner
Bug owner is the person who reviews and owns the bug. Bug owner checks whether the bug information is sufficient or not, if not then the bug is assigned back to the bug reporter to provide more information. Based on the priorities given to the bug, Bug owner takes the ownership of the bug and get fixed it within the deadline.