How do you create a bug report that is sensitive to the recipient? How are you direct without being rude?

šŸ™‹ Questions
, , ,
21

ā€œObservationsā€ are a great way of highlighting something softly to the rest of the team.

22

I mostly work on the sensitivity before a bug is raised. Bringing up potential issues with developers first is usually helpful. They either like to create the bug report themselves after they reproduced the behaviour or I offer raising the bug as a ā€œfavourā€. When they hear about problems first from a mail about a new bug ticket, that can cause issues.
Sometimes itā€™s not the content of the report that can cause issues, but the number. When I have to reject something with 15 bugs in it I try to emphasize that separate tickets were created for a better overview and if they are small problems I put that in the description.

23

I really like these framings.

24

Iā€˜ve made some experiences with developers who feel offended by bug reports, too. My approach are a few things that were already mentioned:

  • follow a workflow which has been established and agreed by everyone who is involved
  • have a template for the bug report and provide as much information as you can (show that you put in the effort)

Another strategy I use is:

  • write it as a comparison of what you expect and what you observe instead of whatā€˜s correct and whatā€˜s wrong

Finally Iā€˜d like to add that there are good reasons why a bug may not be a bug. For example I might have misunderstood a certain requirement or I might have been unaware that I made assumptions at some points, or I might have missed something. I own it and will look for improvements. But I donā€˜t consider it a bad thing that this ā€žnon-bugā€œ exists because it contains some information I wasnā€˜t aware of before which means itā€˜s another source of information. And Iā€˜m a hunter and gatherer :wink:

2 Likes
25

In my experience it is best to be neutral and diplomatic.
Make sure the bug hasnā€™t already been reported.
Write out repro steps.
What is expected according to the requirements.
What is actually happening, with logs or screenshots if possible.

26

Just now I discovered a page called the four-hour tester. It contains short exercises to learn testing and one of them is bug reporting.

I didnā€™t do the exercises yet, so I canā€™t say whether it will be useful for this particular question about sensitivity, but I just remembered this question when I stumbled upon it.

2 Likes
27

The BBST did (does?) have a whole course on bug advocacy, and some others have it to, that includes how to be sensitive to your clients, including setting tone, expressing ideas dispassionately and without blame, and the importance and value of being kind in your reporting to build credibility.

28

Reading through this topic it only came to mind the various ā€˜recipientsā€™ and contexts where things can go in various directions.

  • Devs donā€™t even read the bug reports(they leave it to the product manager to give them what should be fixed, and what outcome the should be);
  • Devs read only a few of the bug reports - then they get bored and ignore the rest - saying Iā€™ve fixed most of them, I think itā€™s enough;
  • Devs interpret however they want the solutions of a bug;
  • Devs wonā€™t fix a bug if it doesnā€™t have an expected outcome/solution/result for the reproducible steps;
  • A Lead PM comes and says, that the format of the bug report(issue, task, storyā€¦) is not the standard one that he knows about and asks me to rewrite all opened tickets;
  • A dev wonā€™t even open the platform - so you mostly have to write him post-its with issues or pair with him;
  • PMs or devs donā€™t like that some report looks like a bug and theyā€™ll delete or rewrite it to look like a feature;
  • Devs wonā€™t read or fix your reported issues because they donā€™t personally like you for finding problems where you ā€œshouldnā€™t be lookingā€;
  • Devs decide for themselves the priority of which bugs they like to fix or are important - ignoring the reporterā€™s or PM suggestions;
  • Devs would think that too many details in a ticket is a waste of his time so they want a quick show or translation;
  • A PM would want the tester to work through the bugs with the devs first before he gets to intervene on more sensitive matters;
  • A dev would want a designer to specify the requirements for a behavior/scenario for which the bug report was made;
  • A lead manager would say, youā€™re reporting too many bugs - so thereā€™s something wrong with testing: a new test process must be established, more automation and early testing to not report so many bugs;
  • Sometimes the PM or Dev doesnā€™t even have the time to read all the bugs, so the recipient is just another tester that might triage; Hundreds of issues will be closedā€¦
  • Sometimes a dev is offended as you reopen a bug multiple times due to the same or new issues introduced - so they want you to create a new one;
  • Sometimes Iā€™ve had devs tell me to fix it(not even caring about the report), as they donā€™t want to open their computer for the next few hours so I solo-fixed or paired with them;
  • You get also the chance to update/re-write some other reported bugs - from stakeholders, colleagues, and designers;
    ā€¦and dozens of other similar situations Iā€™ve experiencedā€¦

I think itā€™s not realistic to say that there is a particular format for bug reports that works in most situations.
As Chris mentioned, you start with a generic guideline, like the one recommended by Cem Kaner, and then adapt your way through the context to deliver the message as efficiently as possible.

2 Likes