During the software QA testing cycle, engineers test the application and report defects. Defect numbers can be high, which translates to additional work prior to release.
Defects must be tracked by developers and testers to ensure important issues are fixed, retested, and moved into the production release build. When time is short, defects can roll into future sprints — most that rollover are not critical bugs, but may be high, medium, or low priority.
Of all the data managed throughout a software development life cycle, (SDLC), defects are the most important. To organize defect tracking, use the Jira fields for Status and Resolution. Additionally, the Environment field plays a key part in tracking a defect’s status as well as in which build(s) the defect exists. In this article, we discuss the relationship between the Status, Resolution and Environment fields.
Ticket Status Fields
JIRA Bug Ticket
Status is a required field which tracks the primary stages of the defect’s lifecycle. When the defect, or ticket, is entered by a tester the status is Open. The ticket is assigned to a developer for coding, and the status moves to In Progress. After a developer has fixed the issue they set it to Resolved. After the defect fix is built into a release for testing, then testers retest the issue and move it to the Passed or Reopened status. When the production build is released, defects in a Passed status are moved to Closed. If the defect is identified in a subsequent build, it is set to Reopened. Defects that are set to Reopened must be moved back to In Progress and be re-processed until they pass testing.
Note that Jira allows users to customize name fields so users can choose names that best fit the SDLC or development team process.
A Typical Workflow Diagram Depicting Status Field Values
Typical Status field values:
- Open: A new issue that is created by not assigned is set to "Open." The issue may be under review to determine if it will be accepted and fixes.
- In-Progress: When a developer is assigned and actively working on a ticket, the status is moved to "In Progress."
- Resolved: "Resolved" indicates that the assigned developer has completed their work.
- Passed: After the QA engineer has tested the bug fix and confirmed it is worked as expected, the ticket is set to "Passed."
- Reopened: When a defect is identified in a subsequent release, the ticket is set to "Reopened."
- Closed: A fixed bug ticket is set to "Closed" when it has passed testing, is a duplicate of an existing issue, is working as expected, or can no longer be reproduced.
Resolution
The Resolution field is not a required field in Jira, however it is a useful field for reporting and root cause analysis. The Resolution value explains why an issue is marked as resolved. For example, the defect may be reviewed and marked as invalid or working as designed. The resolution may also be set to duplicate, or unable to reproduce.
Note that in Jira, users can add any number of Resolution values for team members to select from. By default, the Resolution field has no value assigned and is considered “Unresolved.” Keep in mind, once a value is selected and saved as Resolved, you cannot revert back to Unresolved.
Jira requires that tickets follow a workflow which prevents the field being set back to Unresolved. In a typical development team workflow, users would set the ticket to Resolved and QA testers would retest the defect and set the Status to Passed or Reopened. The ticket would then be moved back to In Progress for a developer fix, and the process continues until the issue passes testing.
Many developer teams use the Resolution field to indicate a variety of status options including:
- 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 if and when the issue status changes. A drop down of valid options can be created if a custom list of values makes it easier for the team to list consistent values for accurate reporting and improved understanding.
Environment Setup
As the application is developed, it is tested at various stages. Developers and the QA team typically work within their own separate environments, so that each group can update independently of one another. Configuring the Environment field values and capturing this information as bugs are entered helps to determine where defect fixes need to be made.
- Development: Sometimes developers and testers are coding and verifying fixes in a shared development environment.
- QA: Code that is unit tested by the developers is moved to the QA environment for complete functional testing, including integration, end-to-end, regression, accessibility, security, and more.
- Production: Production is the live environment where release code is deployed for customer access. Production is typically not tested by developers or QA testers outside of system health checks or smoke tests that don’t add or alter production data.
Production is the live environment where release code is deployed for customer access. Production is typically not tested by developers or QA testers outside of system health checks or smoke tests that don’t add or alter production data.
Whether an in-house team or a software testing company like OnPath, QA testers and 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 move the ticket to completion. Combined with the Environment information, the QA tester knows which server to perform validation and verification testing on. The more consistently a development team uses the Jira fields, the more accurate are reports on team productivity, defect rates, and project progress.
