The value of having good bug-side manners.
It’s not working.
That button that was working last week – today it’s broken. You spent a whole day updating configuration files and setting up your computer and now, after that new build, the key feature for the next release is totally broken. It always happens to you, doesn’t it?
It’s hard being the bearer of bad news. Quite possibly the last thing that someone wants to hear once they’ve finished a task is: “actually… it’s not done yet.” Worse, it’s your job to tell them that they’re wrong, that they made a mistake, and that they need to fix it. We’re up against a lot here. What tools do we have at our disposal?
Changing Perspectives by Exchanging Perspectives
It’s incredibly hard to change minds. In fact – if you approach the conversation with the intention of making someone acknowledge that they’ve made a mistake, you’ve made it harder than it needs to be. All that you need to do is acknowledge that there is a problem, which is entirely true!
Consider it from the developer’s perspective: They’ve just spent a lot of time creating something that they are happy with. To them, the task is complete and meets their level of quality. If you tell them that there is something wrong with their work, you’re telling them that either they misunderstood the task, or that their idea of quality is not good enough. Very few people take this kind of feedback well.
Instead, what you can do is share your perspective with them. It’s not working. It doesn’t need to come with any sort of blame, just the honest acknowledgement that you’re not seeing what you’re expecting. All sorts of things unrelated to the code could be causing the problem. Keep in mind that this might be your fault:
- You could be in the wrong testing environment.
- Maybe you have to clear out your cache.
- You could have just misread the ticket.
If that’s the case, take responsibility for the misunderstanding and rejoice! The ticket is done, no lengthy investigation is needed, and you learned a new trick to try the next time you’re seeing a problem.
If you open a conversation by asking them to walk you through how this new feature works, you’ll get to see them demonstrate their perspective of the new feature to you. If they come across an error during this basic explanation, it’ll be irrefutable proof of a bug. Have you ever tried to test a new feature and observed that the whole thing is totally busted? This saves you all of the awkward conversation and second-guessing. Moreover, getting to see the engineer display their work gives you the opportunity to probe into it with the Socratic Method:
- Who should expect to see this view?
- What would happen if I placed a laughing emoji into that textbox?
- When should the page finish loading?
- Where do documents get saved?
- Why can certain users edit this but not others?
Questioning the design lets developers explore hypotheticals for themselves, which softens the blow of a bug. Realizing that they don’t know the answers to those questions opens them up to hearing those answers.
Ultimately this is your perspective as a tester. You need to look for holes to poke into before the users do. Grace is important here too – you’ll think of things that other people don’t! They might not have the time or creativity to do that. They might not have the distance from the code to look at it objectively. People might be frustrated to get a bug and you’ll need to be sensitive to that. It’s probably written in big red text and it’s probably blocking the next release. Maybe it’s adding stress for their upcoming trip. Guilt and shame have no place in bugs, only delivering a good experience to the user.
Communication is Key
I can’t count the amount of times that I thought a feature was supposed to work a certain way, only to discover that everyone involved had misunderstood each other. Development is a bit of a telephone game between the user, product owner, and developer, and you play as the referee. You’re pointing out where the miscommunications are happening, and trying to correct them before they get back to the user.
I always think of a bug like I’m at a crime scene. It’s a canvas where I can lay out the facts and build it into a case for a change in the code base. If you’re trying to log a bug that’s actually an opinion, you’re trying to do Product Management’s job. “I feel that this form should be structured like so” is very different from: “Our users have said [quote] and our documentation expects [quote] and I observed [screenshot], therefore, [this] change needs to be made”. Once you know something is wrong (and are sure it is not your own fault), start gathering data points and evidence to help guide the developer in their investigation.
- Does this happen in every environment?
- Can you pinpoint the build where this started happening?
- Are there specific reproduction steps?
Anything that can expedite the speed or narrow the scope of their search is relevant information for a bug to have. Linking related bugs or tickets can help your developer connect the dots on the root cause of the bug. All of these things save the team time, and people love when you do that!
Another thing to keep in mind is to use ubiquitous language to describe the problems you’re seeing. Whenever we talk about “the save button” or “the bug from last week” it isn’t completely clear what we’re referring to. Have you ever tested “the patient intake form” only to discover that there are three places in the application where you can do that? I’ve had people ask me to run the “regression test suite”, when what they meant was the “smoke test suite”. Imagine their surprise when I gave them a stack of papers later that week, when all they wanted was a thumbs up or thumbs down. A test by any other name would run as suite. If you ever sense that you could be more specific about something in a bug, make the investment to clarify that for whoever ends up reading it. Sometimes that person is yourself.
While a bug is being worked on, it’s critical to keep ownership of its resolution. Ask about it during stand-up. Make sure that everyone has the same understanding of scope and time-boxing around the fix. Once people start to get different ideas about what’s happening or what needs to get done, the bug unravels into perspectives that need to get reconciled. It’s really easy for balls to get dropped on a development team. A misleading statement in a bug can end up wasting days of a developer’s time, and that can snowball into a delayed release. If the product manager doesn’t understand the risk of the bugfix, it might need to get scrapped at the last second and deliver the bug to users. It’s up to you to track and advocate for fixing this bug because the alternative is the user having the perspective that there is a quality problem. That is much harder to resolve than a single bug.
Celebrate the Victory
Whenever the bug gets resolved, take the time to show gratitude for the effort that everyone put into it. It took yourself, the product manager, at least one developer (but likely a few), and a lot of time and resources into fixing a problem. Sure, it’s everyone’s job to deliver value for the sake of the user. But even though a thank-you might not get remembered, not getting any thanks will always stand out.
I think the best way to thank someone for fixing a problem is to make sure it doesn’t happen again. In this case, automated testing is essential for catching bugs before they get to your doorstep. If the developer has an automated test that checks for these problems before they finish their task, they won’t think of their work as complete until it passes. “Shifting Left” is a term that describes moving tests (left on a graph of time) to be earlier in the development process because it is easier to resolve bugs the sooner that they are caught. If a developer catches an issue during development, the fix is easier than fixing it during release testing, which is easier than releasing a hotfix once customers are dealing with it.
Keeping a good attitude about bugs encourages the rest of the team to celebrate that what could have been did not come to pass. The product is more stable, tests are more thorough, and everyone understands the application (and each other) a little bit deeper than they did before. If you can be proud of both finding and resolving bugs, the team will follow your lead.
Do you have good bug-side manners? Does your team communicate clearly? Is your team relieved to find a bug or frustrated that they have to fix it?
Leave a Reply