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.
Ticket Status 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:
- Open: The issue is ‘Open’ when it is created; it is yet to be assigned to a member of the development team.
- In-Progress: When the assignee is actively working on the issue, it is marked as ‘In-Progress’ state. The estimated time for resolving the issue can be included, often helpful for leads and project managers.
- Resolved: The Resolved status of an issue does not mean that the bug has necessarily been fixed; rather, it is simply an indicator that the current assignee has performed their activities and now the next stage of the ticket’s lifecycle must be addressed. Exactly what that next step is depends on the Resolution field value, discussed next.
- Reopened: In case the issue has not been fixed, it may have to be re-opened when more information becomes available (Resolution: Incomplete/Cannot Reproduce) or maybe it was not relevant earlier but needs to be fixed now (Resolution: Revisit In Future).
-
Closed: A fixed bug ticket is closed according to the process agreed on by the dev team; additional reasons a ticket may be closed mirror the Resolution field value:
- When the bug cannot be fixed
- When the bug is a duplicate of an already existing issue
- When the bug can no longer be reproduced
- When the ticket is redundant, essentially covered in other existing tickets
- When the functionality works as designed
- When the bug is not a real bug
Resolution
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?
- Won’t Fix: The issue in question will not be fixed, based on either business or technical reasons.
- Incomplete: A complete description of the issue has not been provided. The creator of this ticket typically reviews it, adds the necessary detail, and assigns it back to the developer.
- Duplicate: The ticket is identical to a previously created issue.
- Cannot Reproduce: Either sufficient information was not available for the dev to reproduce the issue, or the issue was inadvertently fixed during another code update. Usually the QA engineer will also attempt to reproduce the bug, and if they also fail then the issue can be closed.
- Redundant: The issue details are essentially covered in other ticket(s) in the system.
- Revisit In Future: The issue is not presently relevant to the project application, but in later builds it might be raised as the project undergoes changes and features are added to the application.
- Works As Designed: The issue has been tested and the present functionality is intentional.
- Invalid: The bug is not a valid issue.
The Resolution field values can be edited easily if and when the issue status changes at a later date.
Environment Setup
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.
- Development: Although not a common process, sometimes a dev team will have test engineers verifying code on the same server as they are developing. The bugs raised (Environment: Development) can therefore be dealt with during coding, making for a rapid build/test/fix cycle.
-
Staging:
- QA: Code that is unit tested by the developers is moved to QA for further validation, which includes both manual and automation testing. Tickets raised in the QA environment are assigned back to development for confirmation and fixing, and the updated code is loaded back onto the QA environment for re-testing.
- Pre-Prod: In many companies a Pre-Production environment is used for a test run of all modified code before going to the production or launch stage. This environment is ideal for upgrade testing as well as for regression testing, since it is updated with code that has already been tested in QA and therefore is quite stable. Cloud testing scenarios that simulate user traffic (load and performance testing) is also a good candidate to be performed in here since this environment is often similar in performance and configuration as the Production server. If bugs are found in Pre-Prod, the ticket enters the normal lifecycle workflow, moving from the Dev environment, to QA, and back into Pre-Prod.
- Production: The latest code version is rolled out to the live environment for the benefit of the user base. The more meticulously the application is tested prior to Prod, the smoother the rollout and higher chances of a successful launch.
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.
