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).
...
As a tester, you’ll work on two key types of Jira ticket:
Bug Retestsretests, when fixes come back from Dev. Tracked in “Bug” tickets.
Testing for new functionfeatures or functionality. Tracked in sub-tasks labelled “QA:”
What should I work on first?
For inexperienced testers, or those new to the project, bug retests are typically going to provide an easier point of entry.
What should I work on?
Test queue is Test queues for bugs that are ready to test are here:
https://pathcheck.atlassian.net/issues/?filter=10059 (SAF Apps only)
https://pathcheck.atlassian.net/issues/?filter=10060 (PLACES SafePlaces only)
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.
...
Assign themselves to the ticket
Review the notes on the ticket and add further clarifying information
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 get stuck on a ticket and cannot progress, assign the ticket to “Triage QA” where one of the leads will pick up and review
Review the notes & form a judgment whether they can do the testing
If they can test in the next few days, they should do so
If they can’t test in the next few days, but the testing is fairly straightforward, they should
Add clarifying notes explaining what testing needs to be done
Assign the ticket to “Test Queue”
If they can’t test in the next few days, and the testing is complex or specialised, they should
Add clarifying notes explaining what testing needs to be done, and highlighting the specific difficulties
Assign the ticket to “Triage QA”
Once a tester begins working on testing a bug fix, they should transition the status to IN TEST
Once a tester completes testing of a bug fix, they should transition the status to DONE
If the tester finds problems with the bug fix, they should transition status to IN PROGRESS, and assign back to the Developer. In some cases, it will be worth reaching out on slack as well, to ensure the Dev & Tester are in sync.
New Features workflow
New Features are tracked by either Stories or Epics (with just a couple of minor differences between them in terms of process).
...
Assign themselves to the ticket
Review the notes on the ticket and add further clarifying information
Once you being to work on the new feature, transition status to IN TEST
Once you have completed testing, transition status to DONE
Update the testing you completed for the new feature in the ticket
If you find a problem with the new feature, then transition status to IN PROGRESS and assign back the the Developer
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 stories and epics assigned to Triage QA will be monitored by a team of QA product leads.
When a card is assigned to “Triage QA”, one of these leads will:
Review the information provided by Dev and clarify any missing info
Identify any particular issues that may exist with testing this function, any blockers etc.
Provide detailed set of test guidance for the feature, that a tester will be able to follow
Create one or more sub-task tickets tracking the specific testing that needs to be done:
These sub-tasks always have a name beginning “QA:”
Each sub-task includes detailed guidance on the testing to be done.
See below for details of the life-cycle of these sub-tasks.
The state of the card remains “READY FOR TEST” - testing status is tracked under the individual sub-tasks.
The above applies equally to Epics, Stories, and occasionally to bugs (where the test lead determines that substantive testing is needed for the bug fix, over & around just validating the original bug scenario).
Note that when the card in question is an Epic, an additional child Story card must be created first, and the sub-task created under that.
”QA:“ sub-tasks workflow and tasks
“QA:” sub-tasks are created by product test leads detailing the testing required for an Epic, Story or complex bug
...
Monitor (and manage when necessary) the “Test Queue” list (BUGS)
Keep en eye on the length of the “Test Queue” list, and ensure that we are progressing through the required testing at a pace that will meet our commitments to Dev / PM.
Look out for items that are “stuck” on the “Test Queue” list. Look for any comments that indicate people are struggling to progress particular items. Also look out for items where nobody is commenting, but everyone seems to be avoiding!
Test queues are here:
...