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

Discussions
, , ,
1

Raising a bug with someone is a skill.

There’s subtlety in how we do it. Factors such as who we’re raising it with, the things that person has got going on right now, the time of day, the severity of the bug based on the confidence in oracles and much more!

Sometimes raising a bug can rub the recipient up the wrong way. Not by the fact it’s a bug but by the way it’s shared.

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

And if you’re up for sharing a story, have you ever unintentionally offended someone when raising a bug? If so, what did you learn in the process and how did it change you as a tester?

2

I totally agree to it.

After 8 years of experience, I understood this fact.It’s an art.

Not only raising it advocating for it is also essential.

I learnt a lot about it through this workshop

Also, these videos by Dr Cem Kaner made me understand or helped me in the course of it

I have never had instances where a developer rejected my bug or deferred it for any reason.

But I have a good rapport with my developer So I have a very formal approach to it.

I raise a ticket in Jira sometimes and all other times i send a screenshot to him on Teams and explain the issue.

I have never had to persuade someone to fix my bugs or advocate but I would love to.

3

It can be a challenge to write a bug report that doesn’t offend the recipient. I have a very ironic - tending sarcastic - sense of humor, so I’ve had to learn to keep that out of my bug reports since irony and sarcasm do not transfer well to the written word.

These days, since I work so closely with my team, I’ll speak to them first and start with the assumption that I’ve done something wrong. So I’ll start with an instant message that says something like, “I was looking at Story/Project/Whatever xyz and I’m getting something strange. Could you check that I’ve got everything set up properly please?”

Said check could involve me screenshotting my configuration, or a quick Teams call where I share my screen and walk through what I’m seeing, or the developer rechecking their work on the test system. Sometimes it’s something where the developer can do a quick fix and check in in which case that usually happens.

If I do raise a bug report, it’s generally done in collaboration with the developer, and sometimes in collaboration with the team manager as well. We work together to decide whether something is or isn’t a bug, and what information should be involved before it gets written up. I know this is something that most people can’t do, but it works for us.

The bug report itself, I keep it to the facts. Describe what happened. Describe the reproduction steps. Describe what I expected to happen. Take a guess at what may or may not have caused it, and state whether or not it’s caused any data loss in production (this is critical for our software: it could have repercussions for people’s taxes) and if needed create a followup user story to fix any data loss issues that occurred.

The key thing I’ve found is to keep it factual and provide enough reproduction information that the developer can reproduce the problem. Probably the second biggest factor is not blaming anyone for the bug. Sometimes what gets reported as bugs is unforeseen consequences. Other times it’s something that’s been masked by some other issue, or a problem that’s always been present and now is the time to fix it.

Me saying to the unfortunate developer who got landed with making a horribly complicated IE5-specific page cross-browser compatible “I’m really not trying to make your life miserable” as I reported yet another problem is its own bit of nastiness (fortunately we got on well, and he understood. The page in question was working with an XML data blob, using the IE5-only editable panel attribute, and had/has a positively ridiculous amount of javascript to make it work. It’s so bad that even the people who worked on it frequently would double or triple their estimates because it was that page).

4

Must admit I find the premise of this topic a bit strange. Who would be offended by the fact there is a bug? Has anyone ever experienced offence being taken?

If we keep things factual and to the point why would anyone be offended?

I’ve had people argue whether what has been raised is a bug at all (or a new PBI/work item etc), but that’s different topic I suppose.

5

Careful - I’ve heard even the terminology ‘bug’ can upset some developers, preferring to use words like ‘defect’ or ‘issue’ :joy:

I’ve had issues in the past where it can be that finding a bug then raising it is taken personally by the developer, and in my experience this is an issue with the developers disposition more than anything else. A good tester doesn’t raise bugs for no reason as much as a good developer accepts that for every x lines of code they cut, there will be x bugs - and when you’re working with complex systems, bugs are an inevitable part of the job.

How bugs are raised is an essential part of your ‘ways of working’ meeting, that you should have with your immediate team, ideally before any big projects you might undertake. During this session, everyone on the team will agree how they want to work, this includes everyone on the team including testers and developers, and how issues are raised should be a topic.

If the developer has a particular way they want bugs raised then they should be talking about that then, and vice versa as the tester, you should also push for how YOU want to raise bugs as well. It is not a one way street.

The whole idea is to remove the emotion, allay any ambiguity, have a clear route to take when issues are found - you’re just following the agreed way of working, after all. If that way of working isn’t ‘working’ then, that’s a separate issue that should be brought to the surface as soon as possible, or in a retro perhaps.

Saying this, there are some general ‘rules of thumb’ that in my experience always apply. For example, chatting about the bug with the team before raising a ticket, in my opinion, is always much better received. Providing as much detail as possible is another thing, as testers, we should be doing as it’ll frustrate whoever is looking at the bug much less if they can see we’ve done all the checks we possibly can before coming to them.

6

I totally agree with @whitenoise:

Depending on how ‘upset’ they are… Of course you have to be a bit careful and not write in your bug report ‘this sucks and this bug is bad and how could you write it like that???’

But if a developer gets upset because of a bug … it’s probably not a good developer that cares about quality assurance. In my team they love bugs so that they can fix them. They of course get frustrated sometimes but they also love it.

Having a “no-blame-culture” really works out here. You always have to be a bit careful on how you write stuff of course but in the end we all want quality.

This:

and especially this, this is probably one of the best approaches there is:

Only in immature teams, and not because of the way of writing a bug ticket. But more because of a “bug” ticket. They delivered a new feature… huge one… so I logged several bugs (30+) but all different kind of bugs. And the developer wanted it all inside 1 ticket. Which would have had no overview lol.

7

One developer I worked with was a bit… um. In his view, if it wasn’t mentioned in the specs/use cases/design documents, it couldn’t be a bug because it didn’t deviate from the specs. This led to the kind of craziness where I had to get explicit, documented agreement from the designer that there needed to be a 5 pixel space between a vertical line and the start of the text. The fact that you couldn’t read the text properly because it bled into the vertical line wasn’t relevant: the design document did not specify spacing, therefore a lack of spacing was acceptable.

8

My previous team adopted the idea that whenever a feature that was about to be checked in, the developer would demo it to the test team first. It became quite popular and even the product owner attends the (brief) meetings now to ensure the requirements were properly interpreted. I don’t think I attended one without finding an issue that got to be fixed before first check-in. Maybe an indirect answer to your question.

9

I often ask a question (or five) about what I am seeing while testing. Example: “is this the expected outcome?” This can be used for data checking or if something in the UI looks odd to me.

10

I’ve experienced similar things (for slightly different reasons), but this is difference to “offence” right?

You might disagree something is a bug*, doesn’t mean you’ve taken offence.

(one example for me was when working with an external development team and bugs they needed to fix (for free), so often they’d claim some bugs were in fact CRs, or new backlog items. And also bugs were a measure of the quality of their work so they were quite ferocious sometimes in the classification of something as a “bug” or defect.

11

I have a wish to come and work at the same company @charlie_from_cny . So many “embarrassing” class defects can be flushed out early, in a demo and I really hate it when a team cannot bring themselves to do a demo to everyone in the company. Sure not everyone is proud of their code, but like @katepaulk hints at, if you see something in a demo, wait till the end, then ask politely if that was “intended” to work or look that way. It may be you can avoid having to raise a jira, because the team might see your perspective just because you waited patiently.

12

it’s really hard for someone, who might be on the autism spectrum as a tester, to know if they will offend someone when they write up a bug, so they may end up beating around the bush as to the inconsistency they think is a bug. And end up not getting the bug to stick, and perhaps missing things they really care about. For me, it has to be conversational, “did we want users to do/see X here or did we want them to do Y here?” Always only suggest what to change when you have prior art, try not to ever suggest how to fix a bug unless the fix is really obviously only to do one thing.

13

Oh, this developer got offended that anyone would dare raise a bug against his work. I don’t think he’d ever heard of the notion that we were supposed to be working together to make the product as good as we could get it.

14

That suggestion (the one we use) came up during a Retrospective. If you don’t have those, maybe you could suggest a one-time Retrospective or project post-mortem and see if it gains any traction.

15

Having clear expectations about the team process and responsibilities is essential. In our Product Development Team, I know it’s my job to guide the testing team to find as many issues as possible before a release and to bring them to the attention of the Prod Dev team in the clearest way possible, as soon as possible. It is not my job to prioritize the bug fixes. It isn’t even my job to determine whether the issue is a bug. It could be that the specs were poorly written and the developer met them, but it resulted in a bad user experience. (I could argue about whether that is conceptually a bug or not, but again, that is not my job, haha!)

I can (and do) contribute to the team discussions about prioritizing bugs. I can (and do) ask questions and offer my input on whether something will affect clients enough to warrant a code change before release. But because I know I don’t bear the whole responsibility of getting bugs fixed, I can relax and rely on each team member to do their part as we make decisions to improve the product together.

So I just use a bug report template that gives the devs the information they need, and we can all talk about what to do about it later. It is factual: describing the issue, steps to reproduce, expected behavior, observed behavior, and a screenshot of the observed behavior if possible. I make sure that more than one tester can reproduce the issue before I report it to the team. I’m always open to correction about the expected behavior.

16

This took off. Well I’ll throw in that a bug report is just a communication of a found problem to a developer, written or otherwise. If written bug reports have some special, magical element to them then that could be a process issue. If raising bugs through a tracker counts against my developers then I won’t raise them through the tracker, I’ll find another way. If the template doesn’t describe what I need it to I’ll use my own. If a developer doesn’t understand what I’m writing I’ll use videos, gifs, screenshots, audio recordings or whatever I need to to get myself across. Whatever I can do to get useful, responsible information into the right people’s hands. This is a negotiation with process, the amount of time and effort that it’s expected that I devote to nonsense versus my ability to do a great job. That is my personal responsibility to my clients and the company, despite my clients and the company.

If it’s not the process then it’s all about my relationship with my team, placing myself in service of their success and negotiating boundaries. Finding ways to be helpful to them, get them the right information, review my communications and find ways that suit them best. If I can’t get my found information into the hands of people who matter in a way that can help them make decisions then I’m wasting my time and theirs.

If I can’t make that work then it’s management’s time to manage because I have strict limits on the levels of bad work I’m willing to be forced to do. The levels of ego I have to manage in a team of experts, including mine, already maxes out my meter, and if they’re not interested in working with me to help them despite everything I try, offer, compromise and concede, then I’ve hit the walls of the scope of my interest in the problem and I defer to the experts in suits. Fix the teams or pay to run the silos without me, because the alternative is escalating every problem.

We need to take responsibility to offer the best to our teams, communicate effectively including listening to them, and building trust in our abilities and loyalties. We need to limit our responsibility when it comes to parenting or being a therapist for our team - I won’t take the food out of the mouths of line managers.

Edit: I also don’t understand the “is it a bug?” conversation. That’s pocket sand; a distraction, a deflection, a lie, whatever. It either is a problem to someone who matters or it isn’t. If it “technically” isn’t a bug then I’ll “technically” call it a value-disaster error defect problem issue. If we don’t want to fix it, that’s not my call; if it’s not actually a problem because I was mistaken then I’m happy to hear it; if you come at me with the 5th Edition Developers Handbook and try to rules lawyer my definitions, I can play that game better than you.

17

This is a great point and something I’ve mulled over many times. In some ALM systems we see different classes of work items. I’ve considered what if we just had a generic work item, and bugs etc are just generic pieces of work, just like new requirements etc are. Work can be prioritised based on importance (like it should be anyway, but people just hung up on the term “bug”).

I’ve also created work item types called “observation” as an example where we can just note things generally that look odd, or suss - even though it might not be an out and out “bug” or “defect”

18

Thank you for the encourage @charlie_from_cny . Yes I have been pushing for retrospectives to happen and they are happening now. I think, that just like being very clear about your wish when you write a bug report, one also has to be very clear about your wish when trying to make a team change their rituals and include a demo. I have, in the last while felt like I was the only person asking to change the rituals and even the way we deal with bugs, especially non-engineering defects or tasks. And it has dawned on me, that drafting my questions mentally first, and taking on the perspective of my reader has been missing.

I’ll bet if people could write a defect report, “as if” they were the coder the fix task is intended for, they would write those jiras very much more succinctly and with empathy. Myself included.

19

We’re rolling out more automated tests over the past 2 years. Nothing creates empathy like having your test group start writing code of their own. :wink:
Keep up the good work.

20

I use as much hard evidence as possible and just attach it to the ticket.
If the person is sensitive, I try to just give the dry-version of it, without adding emotions to keep it factual.

here’s an example using Dashcam (a tool I am building to help testers) as a repro platform on a website that had some scrolling issues
HelpKit bug when scrolling

Watch HelpKit bug when scrolling on Dashcam