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