Versions Compared

Old Version 14

changes.mady.by.user Stella Nelson

Saved on

compared with

New Version 15

changes.mady.by.user Diarmid Mackenzie

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

Contents:

Table of Contents

Basic FAQ for Testers

What testing work should I work on?

As a tester, you’ll work on two key types of Jira ticket:

...

Bug retests, when fixes come back from Dev. Tracked in “Bug” tickets.

...

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. Test queues for bugs that are ready to test are here:

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.

...

Resting Bug Fixes

Bugs are raised as described here: How to raise bugs found in Testing

...

When a Tester receives a bug in READY FOR TEST state, they should:

...

Assign themselves to the ticket

...

  • 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

Exceptions:

  • 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

    have too much on your plate, and cannot get to a Ticket assigned to you 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 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

    you get stuck on a ticket and cannot progress, 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. where one of the leads will pick up and review

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

...

  • Set status to READY FOR TEST

  • Include some details of the new feature:

    • Which build will contain the new feature

    • What the design of the new feature is - including links to Figma resources & any other design reference material.

    • Any particular concerns or risks that need particular attention from the QA team.

  • Assign to “Triage QA”

Triage QA will analyze the ticket, determine the required testing, and create a number of “QA:” subtasks (details below), which are then passed to Testers in state READY FOR TEST

When a Tester receives a new feature in READY FOR TEST state, they should:

  • Assign themselves to the “QA:” subtask ticket

  • Review the notes on the subtask ticket and add further clarifying information

  • Once you being to work on the new feature, transition status to IN TESTOnce you have completed testing

  • Update the ticket with details of the testing you completed for the new feature.

  • Once testing is complete, debrief with the test lead (see “debriefs” below).

  • After the debrief is complete, transition status to DONE

Exceptions

  • Update the testing you completed for

    If you find bugs in the new feature

    in the ticket

    , raise them in Jira as described here: How to raise bugs found in Testing

  • If you find a problem blocking bug that means you cannot go on with the new featuretesting, then transition status to IN PROGRESS and assign back the the Developer BLOCKED and link the Jira tickets to show that the bug blocks the testing.

  • If you get stuck on a ticket and cannot progress for any other reason, 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 are created by product test leads detailing the testing required for an Epic, Story or complex bug

They have a life-cycle as follows:

...

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 set to either an individual tester if available, or “Test Queue” if not

...

Now the ticket is ready to test, the tester picks up ticket from “Test Queue” then;

  • Assign themselves to the ticket

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

Debriefs

We run debriefs for “QA:” subtasks. We don’t typically run debriefs for bug fixes, but can do so at the tester’s discretion.

The purpose of a debrief is to review and agree on:

  • What has been learned in testing, and whether any further testing should be planned

  • Whether the documentation of the testing done is adequate

  • Whether any of the bugs found should block us from considering this testing to be “DONE” (typically because the bugs were major, or because significant further testing will be needed once the bugs are fixed).

  • Any testability issues, or impediments, that we should be looking to resolve

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

Roles & Responsibilities

This section explains the key roles within the QA team, and what should be done by people in each of these roles, to keep the flows described above working.

Tester

Our intention is that Testers should have a fairly simple workflow.

A tester shouldA debrief can take sevaral forms, depending on the experience of the tester, and the complexity of what was tested. This could be:

  • a face-to-face video conference, reviewing the testing & bugs in detail

  • or, in simpler cases a brief slack conversation.

The debrief must reach a clear position on whether or not the required testing can be considered “DONE” - and if more testing is needed, whether it will be done under this ticket, or whether a new ticket will be raised to cover it.

Tester Responsibilities

We ask that testers do the following:

  • Assign tickets to themselves that they are working on

  • Always add detail of what you tested, and what you didn’t for any ticket, and review with the test lead

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

  • If the tester cannot complete the 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

Test Leads

Product Test Leads need to regularly (at least once a day) perform the following.

Manage the “Triage QA” list

  • Review all Bugs, Epics and Stories in “Triage QA”

  • Process and create For “QA:” subtasks, always debrief with a test lead before marking the task as DONE

Note that Brand New testers will probably find it easier to start with Bugs, and then move on the “QA:” sub-tasks

...

The Triage list is here:

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:

...

https://pathcheck.atlassian.net/issues/?filter=10055 (All)

...

https://pathcheck.atlassian.net/issues/?filter=10059 (SAF only)

...

when they have a bit more familiarity with the products.

Current Test Leads

Current Test Leads are Diarmid Mackenzie and Stella Nelson , currently sharing work across both SAF and PLACES.

Other experienced testers who would like to contribute as test leads, please do let us know.

See also related article on guidance for Test Leads: