| Info |
|---|
These flows are being developed in late-July 2020, and are intended for use with the SAF and PLACES Jira products (i.e. the GPS Mobile App, and Safe Places). This is an early draft of the processes we hope to follow. Feedback welcome. |
Contents:
| Table of Contents |
|---|
Ticket Types
This section covers the different types of ticket we use to track testing work in Jira, and the main flows that we use.
...
Retesting bug fixes workflow
Bugs in Jira look like this:
...
Bugs ready to test are here: https://pathcheck.atlassian.net/browseissues/SAF-264?filter=10055
When a Tester receives a bug in READY FOR TEST state, they should:
Once you being to work on the bug fix, transition status to IN TEST
Once you have completed testing, transition status to DONE
Update the testing you completed for the bug fix in the ticket
If you find a problem with the bug fix, then transition status to IN PROGRESS and assign back the the Developer
If you are unable to complete a ticket in a reasonable timeframe, please:
Add notes to the ticket so that another tester can understand what needs to be done.
Assign the ticket to “Test Queue”
If you get stuck on a ticket and cannot progress, assign the ticket to “Triage QA” where one of the leads will pick up and review
New
...
features workflow
New Features are tracked in Jira by either Stories or Epics, which look like this:
...
The test activity for such a story or Epic is tracked in “QA:” subtasks that look like this:
...
Bugs are raised as described here: How to raise bugs found in Testing Once a feature is ready for test, the Developer should:
...
New ready to test feature work can be found here: https://pathcheck.atlassian.net/browseissues/PLACES-527?filter=10056
When a Tester receives a new feature in READY FOR TEST state, they should:
...
We ask that testers do the following:
Assign tickets to themselves that they are working on
If they don’t have any work assigned, review work in the “Test Queue”, and assign this work to themselves, and do it! Where set, use ticket priority as a hint as to what order to tackle things in.
Test queue is here:
If the tester cannot complete an assigned ticket in a reasonable timeframe, and that work could reasonably be assigned to someone else, pass that work back to “Test Queue” so that someone else can pick it up
If a tester finds work assigned to “Test Queue” that is not clearly defined enough to progress, they should comment to explain the issue and assign back to “Triage QA” with comments explaining why
For “QA:” subtasks, always debrief with a test lead before marking the task as DONE
...