During the software quality assurance testing cycle, the QA team tests the application and the bug tickets they raise can easily run into the hundreds or even thousands for a large project. Regardless of the number of tickets, they must be tracked and monitored with fields (e.g.status fields) closely by developers and the QA team to ensure a timely and accurate response and closure.
Of all the data managed throughout the life cycle of a bug ticket, arguably the most important are related to its current state, reflected by the JIRA fields Status and Resolution. The Environment field also plays a part in understanding the status, as the location of a bug is often critical to knowing where it is on the path to getting fixed. In this article, we will discuss the the relationship between the Status, Resolution and Environment Fields.
JIRA Bug Ticket
Status - Status is a compulsory field in JIRA, and tracks the primary stages of the ticket’s lifecycle: As the ticket is raised by QA (Status: Open) and assigned to a developer (Status: In Progress), they begin work on it. After they have resolved it (Status: Resolved), it is then typically loaded onto a test environment and confirmed as fixed and subsequently released to Live (Status: Closed) or they have to reopen it for one reason or another (Status: Reopened).
A Typical Workflow Diagram Depicting Status Field Values
Status values may be:
Resolution is an attribute to the issue ticket as it progresses through the workflow. It is not a compulsory field in JIRA, yet it is very helpful in reflecting the health of the project via the Created Vs Resolved Report which was discussed in a previous article on JIRA Reporting Options. It is set at the time of changing the status to Resolved and it explains why an issue may be resolved. The value of the Resolution Field indicates the next owner of the ticket and the actions needing to be taken.
By default, the Resolution field has no value assigned to it and the issue is considered as Unresolved. But once a value is selected and saved, you cannot revert back to an “Unresolved/None” state; according to JIRA the ticket has officially been resolved and therefore must follow through the established workflow, which includes not resetting this field to the original default value. This has been the cause of confusion for many users, but should be understood as the default behavior of this field.
As mentioned previously, when an issue is resolved it does not always mean the bug has been fixed. So, in what other ways could a ticket be resolved without a bug being fixed?
The Resolution field values can be edited easily if and when the issue status changes at a later date.
As the application is developed, it is tested at every stage for functionality and viability.
The developers and the QA team typically work on their own separate servers, so that each group can update their environment independently based on their need; often times the developers are working on the latest code version, while QA is testing on the last known stable build. Configuring the Environment field values and capturing this information as bugs are entered help determine what direction the workflow takes for each ticket.
Note that a ticket should always be verified and closed in the same environment in which it was created, to be absolutely certain it is no longer an issue. This process can differ from group to group, for example sometimes it makes better sense to close a ticket only once it’s confirmed on Prod. The bottom line is that the ticket lifecycle follows an agreed process that all the members of the team understand and abide by.
Whether an in-house team or a software testing company like OnPath, QA engineers and all members of the dev team rely on an accurate representation of the Status and Resolution fields in order to know what actions are needed to take the ticket to the next step in its lifecycle. Combined with the Environment information the QA engineer will know which server to perform final validation and closure on, and can then provide accurate reporting for all stakeholders on the health of the project.