Do you know how to report bugs and give suggestions?

Last updated by Tiago Araújo [SSW] 15 days ago.See history

If you are unclear use IM to ask, but remember the golden rule to not send tasks on Teams.

It is recommended to keep track of active project backlogs on the company intranet, while also including the Product Owner and Tech Lead contact information, coupled with a link to the Teams channel of that project.

When reporting bugs and giving product feedback, it is essential that you are as descriptive as possible. This will save both you and the developer time and frustration in the long run.

Here are the 8 tips:

report bugs and suggestions
Figure: Making the Product Backlog the main source of tasks

Tip #1: Draft your bug with enough details

Make sure you always explain and give as many details as you can of how you got an error or a bad experience. Detailed and useful descriptions can make finding the solution quicker and easier. The goal is to include enough details so the developer can focus on the development work more rather than trying to figure out what the feature requirements or bugs are.

See rule: Do you have a clear definition of a bug? External source: How to produce a good bug report?

Figure: Bad example - This email isn't going to help the developer much - it is vague, has no screen capture or other details to help reproducing the error

Figure: Good example - This email includes the product name and version, the category of the issue (BUG), a screen capture, and informs the user's system

When possible, a great template to follow is the Functional Bug template from the ASP.NET open-source project. Spending time to provide as much detail as possible, by ensuring you have the 3 critical components:

  • Steps to reproduce,
  • Expected outcome, and
  • Actual outcome

Figure: Bad example - Lack of details

Figure: Good example - We can easily identify more the one way to improve the UX and there's a clear suggestion to action

Better than a good textual description of a bug report is a screen recording. This should be followed for a more detailed report. Use Snagit or Camtasia to record your screen.

Video: Good example - Recording bug reports in a video can make the issue clearer to see (1 min)

Recording a stepped user flow of actions that walk through through an issue is another excellent way of reporting a problem that is easily understood and reproducible. There are many tools you can use to make recording these steps easy, for example Steps Recorder which is built in to Windows, or Microsoft's Test & Feedback extension for Chrome, Edge and Firefox.

See our rules for setting up and using these tools at Do you use Problem Steps Recorder? and Do you do exploratory testing?

psr3
Figure: Good example - Using a tool to record steps replicating an issue is a great and simple way to report a problem that's easy for a developer to understand and reproduce

Tip #2: Draft your suggestion with the complaint and what you expect to see

Define all the requirements as per Do your User Stories include Acceptance Criteria?

Better than a good textual description of a suggestion request is a screen recording. This should be followed for a more detailed report. Use Snagit or Camtasia to record your screen.

Video: Good example - Giving suggestion requests via video (5 min)

Tip #3: Should you send this to the Product Owner or the Tech Lead?

It depends on the team, but often the Product Owner is busy. If you know the Tech Lead and your suggestion is obviously a good one, then you should email the Tech Leader and Cc the Product Owner. The Product Owner can always reply if they don’t like the suggestion.

For a bug email:
To: Tech Lead
Cc: Product Owner
Subject: Bug - {{ SUMMARY OF BUG }}

For a new feature email:
To: Tech Lead
Cc: Product Owner
Subject: Suggestion - {{ SUMMARY OF SUGGESTION }}

Tip #4: Should you email or put it in the backlog?

Always go for backlog if you have access to a backlog management system otherwise email relevant people. You may have a group email such as all@northwind.com.au, You would only Cc this email when a greater visibility is required.

Tip #5: Do you make it easy to find all the backlog in your company?

do you know how to report bugs and give suggestions
Figure: An intranet page with links to projects’ backlog to make it easy for everyone to find. Note some projects have more than 1 backlog.

Tip #6: Make sure when using backlog, the Product Owner will still get an email

Create an Issue/PBI and @mention relevant people (GitHub and Azure DevOps will generate a nicely formatted email)

See rules on Do you know when you use @ mentions in a PBI?

Tip #7: Separate PBIs

If they are all related to one area, then you could consider put them together, otherwise don’t bunch them up.

See rules on Do you send tasks one email at a time?

Tip #8: Use emojis and prefixes for PBI/Issues titles, or email subjects

When you create a bug/suggestion to a backlog, it's a good idea to add emoji in the title. Not only does it look nicer, but people can look at the item and take in the necessary information quickly.

This means that anyone looking at the backlog can glean its nature at a glance, rather than having to read each item to know what category it is (5 bugs, 2 features, etc). Examples:

  • 🐛 Bug - Calendar is not showing on iOS devices
  • ✨ Feature - Add 'Back to menu' item to top navigation

We have a proposal to change the standard for a bug from 🐛 to ⚠️ - Vote here.

Check out the rule on Do you know which emojis to use in Scrum?

Tip: GitHub Issue Templates can help you with that.

We open source. Powered by GitHub