Versions Compared

Key

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

...

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.