How we are

...

using

...

Jira

...

• 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.

...

for Bug Tracking

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

...

for ingression of an issue to Jira

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 create 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.

...

...

• Please make sure that the Project is set to “GAEN Mobile (GAEN)”

• That the Issue Type is set to “BUG”

• Before submission, ensure you allocate it to the latest sprint by indicating the sprint name under Sprint field. This is to ensure the team will look at your raised issue/bug record. You can go to Jira Board to check the latest sprint.

Bug Format

• In the Summary field Input a brief overview of the issue, if possible outline a short specific occurrence
  (Ex: “Android > Settings: Button “English” does not open language choice screen”)

• For the Description, please be concise specific and provide steps on how to recreate the issue so the Devs are able to discern how to address the fix.
  
  The Format for bugs is:

...

• If you have a screen shot or screen capture, upload the file to the Jira server

• If this issue is related to another issue, you can input the ticket number to the “Issues” field

• If the issue is SPECIFIC, you can input a Label - (Ex: Translation)
  [Please do not create new labels unless specifically advised to do so]
  

Here is an example of a bug previously used:

...