How to raise bugs found in Testing

Owned by Diarmid Mackenzie
Last updated: Jun 04, 2020

We raise bugs found in Testing in Jira.

Before you raise a bug, please check whether the bug is already known - use the Search bar in the top right of Jira for this.

If you do find an existing bug that matches what you have seen, do consider adding some additional notes to it, if you think you have any additional useful insights.

If you can’t find a duplicate of the bug, please go ahead and raise a Jira bug to track the problem you have seen.

On pretty much any page in Jira, you will find the “create” button near the top - click that to start raising a bug.

Choose the appropriate Project (probably either SAFPATHS TECHNOLOGY or SAFEPLACES TECHNOLOGY).

Set the Issue Type to “Bug”

Then fill in:

  • A Summary of your bug

  • A Description of your bug, which should include (at a minimum)

  1. Details of your device (which phone make, model, OS version, browser etc.)

  2. What build/software version you were testing

  3. Steps to reproduce the problem

  4. What you see

  5. How that differs from what you expected to see

  6. Any references you can provide that explain what you had expected to see (e.g. spec, requirements, behaviour of a previous version etc.)

  7. Screenshots or videos of a repro where you think these will be useful and can easily be provided. Screenshots can be pasted directly into the Description field.

  • Any other attachments that may be useful (log files, videos etc.)

  • Other fields as you see fit. You can leave Assignee as Automatic.

A couple more things to make sure your bug gets seen by the right people:

  1. Allocate the bug to an “Epic” - the general area of work in which it was found. If you aren’t sure what this should be, put some notes explaining your uncertainty in the Description. (Note:Epics SAF-518 (Safe Paths) & SAF-519 (Safe Places) can be used for bugs not asociated with current feature work).

  2. Allocate the bug to the correct Sprint. At time of writing (4 June) any bugs for MVP1 should “MVP - June 5”


Both these fields are set in the right hand panel, scroll down to see a “Show more fields” panel that looks something like this, and click on it.


You can then find the “Epic link” and “Sprint” fields, and fill those in (with a helpful “search” to help you find the relevant Epic if you don’t know the number).

Then finally, hit the “Create” button at the bottom right of the pop-up window:

 

In general, bugs submitted to Jira will be picked up, but not always quickly, and they may not always have wide visibility.

If you think your bug needs wider visibility, perhaps because it is urgent, or severe, or will block other activities (or maybe you are just proud to have found such an awesome bug!), please also post a link to it in a suitable slack channel (e.g. #testing if it will block other testers, #scrum_team_safe_paths if it needs Dev attention etc.).

What if you have feedback, but you aren’t sure if it’s a bug?

Sometimes testers spot problems with the product that aren’t “bugs” as such, btu are still important issues that need to be raised.

  • Maybe the screens match the UX design, but there is still some usability issue.

  • Maybe there is some missing feature, and without it, the end-to-end flow is going to cause problems for some user

  • Etc. etc.

If you see problems like this, please do raise them (checking for existing duplicates, as always).

  • It’s fine to raise something as a “bug” initially, and then convert it to a story when we decide it needs to be handled as a new bit of function, rather than a bug fix.

  • Or, if it’s obvious that the concern you have is a missing feature, not a bug, then you can raise it directly as a Jira “story”.

While bugs in function will mostly get fixed fairly quickly (expect maybe for a few cosmetic ones, which we might decide to live with), new function won’t necessarily be added quickly - there’s a huge list of open ideas for product enhancements already, and limited technical resources to implement them.

Ultimately PM drive what gets implemented, so if you want to make the case for prioritization of a particular feature, you’ll need to persuade the PM team. You can either reach out to them directly, if you already have a working relationship with them, or else discuss with your test lead first.

If you don’t yet know who the PM is for a given product area, chat to your test lead first.