Draft - Diarmid reviewing with John Schoeman
How we are using Jira & Trello & why…
As we increase the number of people actively using the GAEN app, we want to set up more formal bug tracking.
Prior to this point, bugs have been tracked alongside all other Dev work as “To Dos” cards in Trello. There are 2 key reasons to prefer Jira to Trello for bug tracking going forward:
We can open access wider. Whether it is for reporting bugs, or checking for existing bugs, there are good reasons not to open up broad access to the Trello board.
Jira offers various more powerful capabilities - linking between issues, better search, more rigorous tracking of state, better search etc.
The Dev team plan to continue to use Trello as their primary task management system. This means that bugs will end up tracked in both Trello and Jira.
If a bug is already tracked in Trello, is it necessary to create a bug in Jira as well?
From the point of view of making sure the bug gets prioritized & fixed, there is no need - the Trello card will do that job perfectly well.
The key value of creating a Jira ticket is in helping testers & those supporting our customers (both HDs and end users) to know that the bug exists, and what the status of it is. Being able to discover what bugs are known using a single interface (Jira) becomes increasingly valuable as the number of people involved with the project who are more distant from Dev (Testers, Support & HD personnel) increases.
So, who creates bugs in Jira?
Testers, working outside the Dev team
Folks providing technical support to Health Departments (in rare cases this may include HD staff themselves).
Folks providing technical support to end users (e.g. ZenDesk) who may learn of a problem that way.
In general these people will not have access to Trello, and even if they do:
We don’t want to encourage them to create & move Trello cards: having too many people doing that creates project risk
We don’t want them to have to search Trello for duplicate bugs - the search capabilities are not as powerful as Jira.
Hence these people should create bugs in Jira even if the bug is already known and tracked in Trello. In general it will be the responsibility of the Devs to spot when this happens, and link the cards to each other.
When the Dev team create bugs, they do not typically create a bug in Jira. Many Dev bugs will relate to function which is not yet exposed to testers.
The principle we follow is that:
Just because a Dev found a bug does not mean that a tester is likely to find it before it gets fixed.
If one tester found a bug, then other testers are likely to hit the same problem, and will want to know about it.
Process specifics
If someone outside PM/Dev finds a bug in the GAEN solution, they check Jira for duplicates and
if there is no current Jira ticket, raise a Jira bug against the GAEN project.
if a Jira ticket does exist, add any additional information that may be worth recording.
Dev monitor the set of bugs raised <monitoring mechanics TBC>, and:
if a Trello card exists, they link the two tickets together
if no Trello card exists, and the bug should be prioritized for consideration by PM/ Dev, create a Trello card and link the two tickets together
if no Trello card exists, and the bug is not a priority, add a note explaining why.
When Dev complete a Trello card with a related Jira bug, they send the bug to Test for retest <exact mechanics TBC>