Quality issue reporting

Why does it matter?

A well written issue will reduce the amount of back-and-forth communication required between the client and the developers by clearly stating the goals and expectations in play from the very beginning. 

A well written issue will:

• reduce the cost of development by reducing time taken for developers to find the cause of the issue
• reduce the cost of development by preventing issues from being sent back to developers for changes due to misunderstandings around the user goals
• help identify any alternative solutions by maintaining a focus on user goals and not specific software interactions
• keep development focused on the higher-level goals of the project and allow developer to spend time on the work that provides the most value

What makes a good issue?

• Keep It Small: An issue should be as small as possible and address only a single bug or feature. As a rule of thumb, if an issue can be "partially completed" it likely needs to be broken into smaller issues
• User Goals: What were you aiming to achieve when the issue occurred? Try to keep it as high-level as possible, so instead of "I want to submit the order form with Jan 21st as the date", try "I want to place an order for Jan 21st"
• Expected Behaviour: What should have happened?
• Actual Behaviour: What happened that was not expected?
• Steps to Reproduce: What was done prior to the unexpected behaviour that developers can use to reproduce the issue for investigation? What information was input of what buttons were pressed?
• Background Information: Further information developers may need to reproduce the issues. This may include:
  
  • What account were you using when the issue occured
  • What version of your operating system / browser were you using when the issue occured
  • What was the URL of the page you saw the issue from (copied and pasted into the issue)
  • Any files that may be relevant to the issue (attached to the issue)
  • Screenshots of what you are seeing