Creating Issues
-
Always tag issues with the appropriate information (ex.
frontend
,bug
,urgent
, etc..) -
Add the issue to the relevant iteration or generic backlog project board.
-
Link your issues to associated pull requests.
Bug Reporting
Include the following information in bug reports:
-
One bug per report. This is the golden rule of bug reporting. Each bug deserves it’s own bug report. Why? Because it makes it so much more difficult to resolve bugs when you need to hunt through a bug report that has multiple issues listed. Keep it simple, people!
-
Where were you in the software when the bug occurred? Include the URL of the page where the bug is located if it’s a web application.
-
What were you doing in the software when the bug happened? You may hear this referred to as steps to recreate. When a bug is replicable (able to be recreated) it’s easier to work out what went wrong and to fix it.
-
What were you expecting to happen? If a bug is software working in an unexpected way, you need to say what you expected it to do.
-
A screenshot or screen recording of the bug. If a picture is worth 100 words, including a screenshot or screen recording of the bug in your bug report may prove easier than trying to explain what you’re experiencing.
-
Record technical information. Include information such as your operating system, what browser you are using for websites and web applications. Include whether you were using a desktop or mobile, if it’s not already clear.
-
Include any error messages and codes you received. If you’re getting a specific error message or code, it will be helpful when pinpointing what the bug is and how to resolve it. Note, unhelpful error messages and codes can be minor bugs themselves.
-
Can you replicate the issue? Does the same thing happen every time you try to complete the task you’re doing? Including this information in bug reports will help the developer find the cause of the bug.
-
How urgently does this bug need fixed? How much a bug affects your ability to complete the task you want determines the order in which bugs are resolved. You may hear the term priority or severity used to determine how important bugs are and how quickly they need to be fixed. Typically severity varies from Very High (it stops you from working completely) down to Very Low (cosmetic changes). Including this information helps development teams prioritize the order they resolve bugs.