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 |
|---|
Basic FAQ for Testers
...
Bug Retests, when fixes come back from Dev. Tracked in “Bug” tickets.
Testing for new function. Tracked in sub-tasks labelled “QA:”
For inexperienced testers, or those new to the project, bug retests are typically going to provide an easier point of entry.
...
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).
...
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
...
Initially created as OPEN, with an owner of either:
The test lead; who will detail the testing to be done
or “Triage QA” if there’s no-one immediately available to articulate the detail of the testing.
Once the required testing is defined, and ticket is suitable for testing, the card is updated:
Status moved to READY FOR TEST
Owner is moved set to either an individual tester (if there is already a clear plan for who will do the testing) if available, or “Test Queue” if there is not
Once Now the ticket is in READY FOR TEST state, and assigned to a tester, or to “Test Queue”, it is handled as follows:
Tester takes ownership of task on “Test Queue”ready to test..
The tester picks up ticket from “Test Queue”, assigns to themselves, then;
Performs the testing outlined in the ticket
Raises any issues / concerns about the scope of testing with the Test Lead.
Raises any bugs as necessary and they involve the Dev team and/or a QA lead in the event of any issues.
Records details of testing performed in the ticket
For lightweight notes, this can be directly in the ticket
For more extensive notes, they can link to a Test Report filed in Confluence (E.g. here: Test Reports)
Once testing is complete, before transitioning the ticket to DONE, they have a debriefing conversation with the relevant test lead, covering:
What has been learned in testing, and whether any further testing should be planned
Whether the documentation of the testing done is adequate
Any testability issues, or impediments, that we should be looking to resolve.This can be an in-person live conversation, or it could be an exchange in Slack.
Once this debrief is completed, the ticket can be transitioned to DONE.
Note that a testing ticket can be transitioned to DONE, even if there are open bugs raised in that testing, as long as the tester & the debriefer are happy that the bug retests to follow will adequately cover the remaining risks. This will typically be the case for minor non-blocking bugs, but will typically not be the case for major blocking bugs.
...