Bug Reports
Bug reports should aim to follow the basic bug template as outlined below:
[User role experiencing the issue]
Steps to reproduce: 1. Step 1 2. Step 2 3. Step 3
...Actual Result
This is what happens when you do this on the live siteExpected Result
This is what you thought was going to happen
Our customer service team utilizes FreshDesk for ticketing, which is integrated with Jira so that they can create bug tickets in FreshDesk and the appropriate Jira backlog at the same time. The above template exists in FreshDesk as a template for the convenience of our customer service team.
Our QA team has access to the developer backlogs in order to report their bugs directly.
Developer Process
The development team's role in bug reporting is the assessment of bugs and execution of releases and hotfixes (as appropriate; see below).
New bugs added to the Marketplace and Portal Platform Jira projects will automatically ping the bug-reports slack channel. New bugs reported via FreshDesk will appear at the bottom of the Jira backlog by default, but should be reviewed and prioritized as necessary.
Bug Status
When a new bug is added to one of the development backlogs, a developer must assess the status of the bug and update the issue accordingly; there is a custom field in Jira called Bug Status, which must be assigned one of two values: Accepted or Won't Fix.
Accepted indicates that this bug has been evaluated by a developer, and it has been determined
that this is an issue we intend to work on.
Won't Fix indicates that a developer has determined that the reported issue is not truly a
bug, or is something that we do not intend to address at this time.
If a bug is marked Accepted, it must then be prioritized according to the severity of the bug
and/or the desires of the Product Owner(s).
If a bug is marked Won't Fix, it should be sent to the bottom of the backlog, and will be
re-evaluated at a later date (and possibly removed entirely).
Priority
Jira has five levels of priority that may be assigned to issues; we have come up with corresponding guidelines for each level to help Simpatra staff determine how to prioritize any bugs they may find.
| Priority | Description |
|---|---|
| Highest | This is an emergency. A developer must drop what they're working on in the sprint and immediately change tack. Reaching a resolution takes precedence over an elegant solution. |
| High | A developer should begin investigating this bug the same day it is reported. This task takes priority over previously established sprint work. A resolution should be reached as quickly as possible. |
| Medium | Investigation should begin as soon as a developer has finished the current story they are working on in the sprint. It should be resolved (if possible) before work on other sprint tasks is resumed. |
| Low | This bug does not take priority over current sprint work. It should be prioritized in the backlog according to the needs/wants of the company and Product Owner(s). |
| Lowest | Reserved for bugs that are non-breaking, or have easy work-arounds. These are not urgent, and will be prioritized in the backlog accordingly. |
Bugs may come through from FreshDesk with a priority already assigned to them; it's important that we verify the severity of the bug with the reporter in cases where it interrupts sprint flow. We want to ensure that we are spending our development time as wisely as possible, and aren't prioritizing bugs that have serviceable workarounds incorrectly.