RFC: Bug reporting and prioritising

[boredsteve]

Description

Bug tickets on MyWorksite were sometimes vague and lack context, which creates an overhead for the dev assigned the ticket to hunt down the reporter and force information out of her/him. Kerry and I then came up with a process and format for bug reporting tickets, which we hope would make it easier for the assignee to start reproducing and working on it quicker. Might be worth adapting for other projects.

Workflow

Reporter finds bug
Log in to JIRA and create a bug ticket with the following info:

• Summary: Self-explanatory
• Priority: PMs or Tester to assign
  • Blockers - Bugs that needs to be fixed before deployment of release, goes into active sprint and takes priority over all other tickets
  • Critical - Bugs that had been deployed. Goes into active sprint as well, needs hot-fixing and deployed
  • High - Bugs that needs to be fixed in current sprint
  • Normal & Low - Goes into backlog for refinement and discussion
• Assignee - Tester to assign back to develop who worked on ticket, or volunteered
• Reporter - Self-explanatory
• Environment - Environment where bug was found e.g. Local (git branch), Dev, UAT, Prod
• Description - Any relevant information about bug, e.g. repro steps, user logged in with, error messages
• Attachment - Screenshots or relevant attachments

[anotheredward]

Would be good to have a standard "Description" format, eg:
Must have Repro in this format:
Actual:

1. Log in to https://dev1.myworksites.co.nz/ as [email protected]
2. Shows (the attached) 404 error page

Expected:

1. Log in to My Leapfrog as user x
2. Shows home page

Attach screenshot, preferably with a red box highlighting the issue, where appropriate
Attach entire error page, copy of errors from JS Console where appropriate
Attach any resources, files to upload, where appropriate for the repro

Rather than navigating, direct urls are strongly encouraged :)
Logging in can generally be assumed, as long as you provide a specific user.
If there any labels, fields, or buttons you want to refer to, put their names in quotes, eg: 3. Click the "Create New TMP" button
Lastly, using the same, unambiguous vocab to mean the same thing consistently eg" Navigate to" and "Click" rather than a mix, or ambiguous words like "Enter" can speed up both reading and writing of bugs. (I am a big fan of: Click "labelName" for most things)
We should probably specify this vocab here, along with a few example Descriptions

[anotheredward]

Would also be good to document a basic process for testing, a tester is nowhere near done when they find an error:
https://spin.atomicobject.com/2015/03/20/rimgea-testing-mnemonic/

And a test sheet for inputs:
http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf

[anotheredward]

@boredsteve Could you please PR to add this to the "testing.md"?

[anotheredward]

Also, having a standard summary format can really help scanning, eg:
One example is: "(user) should/should not (action) (page/feature)"
"STMS should not see all TMPs"
Another one is:
As a user...

The reason for using "should" is that summaries are often unclear if that is how it should work unless you have a lot of domain knowledge, eg:
"STMS sees all TMPs"

Could mean:
"They should see all TMPs, but they don't"
or
"They see all TMPs, but they shouldn't"

[anotheredward]

Is this still useful @boredsteve or would we like to close it off?