Bug reporting guidelines

Updated 2,858 Days AgoPublic

Actions

How to report a bug

• Make sure your software is up to date
• Search for the bug in the ticket system, see if it's already there - if yes, and you have something to add do it as a comment
• Figure out the steps to reproduce a bug
• Take screenshots / screen recording if possible / relevant
• Copy logs from application whenever possible
• Specify the operating system, OS version and hardware
• Include the full software version
• If you have multiple issues, please file separate bug reports
• Open a new ticket on phabricator and assign it to the team lead (they will be notified about it and can later prioritize and re-assign them)
• Please understand that the ticket system is also used by devs to organize/follow their work so:
  • Set priority to the bug only if You really think that it's critical, and don't change priorities after the task is re-assigned and/or re-prioritized - if you think that an issue got a low priority, please send a mail to the team lead and ask them before messing with already prioritized mails
  • Don't re-open tickets closed by developers, if you think that it should be re-opened, write an email to the team lead and explain why ( the bug came up again, it's not fixed the way it should be) - or open another ticket.
• Try to answer the following questions in your bug report:
  • What did you do to get the problem? Minimized, easy-to-follow steps that will trigger the bug. If they're necessary, make sure to include any special setup steps - With screenshots / screen recordings
  • What was the expectation? What the application should have done, were the bug not present. An example would be: The window should scroll downwards. Scrolled content should be selected. Or, at least, the application should not crash.
  • What did You get, or Actual Results: What the application did after performing the above steps. An example would be: The application crashed.
• Attach application/http/etc. log at the end of the report when possible

What should you include in bug report?

• Description: The details of your problem report
• Indicate whether you can reproduce the bug at will, ocasionally, or not at all.
• Describe your method of interacting with the app in addition to the intent of each step. Examples:
  • GOOD: 1. start the app with icon, 2. log out if you have a user logged in, 3. register a new user, 4. upload a really huge image when asked, etc
  • BAD: Trying to upload an image
• After your steps, precisely describe the observed (actual) result and the expected result. Clearly separate facts (observations) from speculations. Example:
  • GOOD: Expected result: getting the image to show above the upload button on registration screed, Actual result: preview div disappears
  • BAD: It doesn't work

Things to avoid

These are common mistakes when providing reproduction instructions:

• Insufficient Information: The most common issue we see is instructions which do not have enough information: they are missing critical details which are necessary in order to follow them.
• Inaccurate Steps: The second most common issue we see is instructions which do not actually reproduce a problem when followed. Verify your steps by testing them.
• Screenshots and Screencasts: Screenshots can be helpful to explain a set of steps or show what you're seeing, but they usually aren't sufficient on their own because they don't contain all the information we need to reproduce them. Also, screenshots and videos cannot be searched. Someone reporting a new issue will not be able to find existing ticket that are potentially related to existing issue(s).

Bug fixing workflow

• After reporting a bug, please make sure that you help answer any questions that the developer might have in order to help locate and fix the bug as soon and as easily as possible
• When the developer considers the bug fixed, the ticket status will be updated to testing, when ticket has this status, and the fix goes out in the next build (test build) please make sure to see / test if the bug is really fixed, and just leave a comment on the ticket : verified, all ok so the developer can close the ticket - or , if the problem still exists, provide more information to help with the fix
• Tickets with 'testing' status will help testers to see what went out in the newest bug, and they will be able to go through them - test the fixes
• Developers should mark a ticket as 'resolved' only if the ticket was created by them for them - then it's no need for this status change dance.