On a typical morning, my workday begins with me opening my email to see what's happened while I was sleeping. I work on the opposite side of the globe from most of my team. There's often plenty of catching up to do before starting my day. As a software engineer, I usually have plenty of emails from the various systems and services that the company uses - GitHub, Notion, our continuous integration service, etc. Most of the emails are updates on work I've done, but a few also come in the form of bug reports from our QA team.

On a typical work morning, I'd have a couple of bug reports from my current projects. No one likes receiving bug reports, but they're inevitable in our line of work. Depending on the day, I can have a less-than-favorable response to those reports. Admittedly, it often depends on whether the caffeine I've consumed has kicked in or not, but I digress. Here are a few legitimate reactions that occurred while reading these reports:

"Oh great, another bug report with a handful of sentences that don't explain anything related to the problem."

"*Sigh* I wish this person pinged me on Slack before filing this bug - I could have explained why it's not a bug and saved both of us from dealing with this report."

"I don't know why they think that's the solution to the problem; it's much more complicated than that. Ugh, let the software development to the software developers."

I admit - those are not my proudest moments, and I acknowledge that it's not the best to have such an immediate reaction. But I can't deny that I've had these feelings before, and I'm sure many software developers go through similar routines daily.

Currently, I've been working more closely with test automation engineers doing more hands-on automation work. I've seen the other side of those bug reports. I've seen incredible amounts of anxiety from testers, thinking that they're stepping on the development team's toes when logging a bug. There have been moments where testers run into nearly immediate resistance from developers. In some instances, bug reports get closed with no explanation whatsoever.

It's often a side of things that developers don't see. In most cases, developers don't realize what they're doing. It all adds up, and it can make testers feel like they're doing a poor job, even though they're doing everything as they should. These feelings eventually erode the trust the team has in each other, and will inevitably lead to low-quality output on all fronts.

While I genuinely believe that testing and development should be working closely together, unfortunately, it's common that both of these teams work in their bubble. Having a bit of separation between both disciplines is what leads to massive misunderstandings down the road. But there doesn't have to be a huge gap between one side and the other. Everyone can work in harmony if they're aware that each side is doing their best.

As I've worked more closely with other testers, I've seen a few common traits that have helped keep the peace between QA and development. If you feel like reporting bugs is a painful task due to perceived (or actual) hostility, here are a couple of tips that can ease that friction with your developers.

Talk to the developers first before logging that bug

Developers can sometimes gain the reputation of needing to be completely undisturbed during work hours for peak efficiency. While it's true that knowledge workers need certain amounts of focused time for problem-solving, many interpret that a bit to the extreme. Unless there's an emergency like websites being completely offline or the building being on fire, some team members don't dare interrupt developers. They think they can't ask for some time from a developer without upsetting them.

For more developers, that's not true. It's still a common occurrence. It even happened to me. Not so long ago, I had a situation where I experienced this first-hand. I discovered someone on the QA team felt very uncomfortable in pinging me because they thought I would be annoyed at them. We cleared it up, but it made me think how common this is on other teams.

In my experience, it's not uncommon to have testers bypass talking with the development team and solely log bugs in whatever tracking system the company uses. This practice helps the developers focus on their work, but more often than not, it can lead to worse issues for everyone on the team, testers, and developers alike.

When the QA team logs bugs without consulting the development team, they can miss valuable context that would make a bug report more helpful to the development team. For most bugs, developers can have an idea of what caused the bug, which adds valuable data to the bug report. For example, the developer accidentally introduced the bug in a new feature they were working on recently. In this case, they will know where to look first instead of going on a wild goose chase. In some cases, the bug could already have a fix in an unreleased development branch. You'll avoid wasting your time and the time of the rest of the team.

By talking with the development team and gaining further insight about a particular bug, you will be able to include enough information to make it easier to fix. Well-informed bug reports will lead to quick turnarounds from the development team since they'll have enough information to get to work quickly.

If you work as part of a remote or distributed team, you might not have the luxury of talking to the development team immediately. You may have no choice but to log bugs first to avoid delays. If this is the case, you can still benefit by trying to reach someone after logging the report.

Log the bug with sufficient detail

The main thing to ensure when logging bugs is that it has enough information to help the developers isolate and fix the problem. The amount of information needed and even desired will vary by team, so it would serve everyone to come to an agreement on what level of detail the testers and developers need. Some of the main areas to focus on when logging a bug report should be the following:

Summary of the bug

A clear and concise summary of the bug on your bug tracker's subject line or top of the story speeds up the bug triage process. It gives the rest of the team enough information at a glance to make decisions without having to dig deep in the report. For example, instead of writing Bug when accessing the project reports as your subject line, write Project reports page doesn't display all active projects.

Expected outcome

Telling the developers what you expected to happen can clear up the confusion by making sure everyone's on the same page. It's surprisingly common that testers are waiting for something to happen that is not the same as the product or development team built. By setting expectations early, you can help the team determine if this is a legitimate bug or miscommunication that doesn't need further investigation.

Actual outcome

Here's where you'll explain what happened, what you consider to be the bug. Including this information will help the development team reproduce the problem on their development machines. Once the problem is reproducible, the bug will be simpler to fix. More importantly, the bug can be covered in future regression tests to make sure it doesn't rear its ugly head again.

Steps to reproduce

Take the time to write details on how you got the bug to happen. Just like writing the actual outcome, having a step-by-step guide will assist in reproducing and squashing the bugs. Don't skip this section, even if there are just a handful of steps that you consider obvious. Remember that you won't know who's fixing this bug, and it can be someone new on the team who isn't familiar with the product.

Screenshots or videos

Lots of direct detail helps, but including a few screenshots or even video of your testing and triggering the bug brings the point home. If you've added enough information in your bug report, pictures and videos are a nice-to-have. But I guarantee the development team will undoubtedly appreciate the extra information.

Prior discussions you've had with the development team about this bug

If you spent time talking with a developer before logging the bug, include any notes or comments from the conversation in your report. It's most likely that the developer you spoke to won't be the person responsible for fixing the bug. You can help the person assigned to the bug-squashing with the extra context you received before filing the report.

Resist the temptation to offer solutions

For some bugs, the answer might look very simple to you. If you're logging your bug report and think you know what needs to be done to fix the issue, resist the urge to include it in your report. Focus only on facts in your report, and avoid any speculation on your part even if you think it's a sure-fire way to solve the problem.

You might think offering a solution is helpful, but it can potentially be detrimental to the development team. If the developer in charge of the bug knows that your answer is incorrect, it will erode their trust in your abilities. If the developer follows your solution and it's not the right one, they'll end up wasting their time, which will also annoy them. Even worse, if a newer developer who isn't familiar with the codebase yet implements your solution, they could be introducing future bugs or regressions.

Instead of telling the development team how you believe a bug should be fixed, mention it as an idea instead of a solution. There's a big difference in saying This should be fixed by doing _____ and saying Do you think doing _____ will help? The developers will accept suggestions quicker than perceived orders. Even if your idea isn't the right now, developers will be more receptive to your help.

The purpose of this article isn't to make sure your development team is happy at the expense of the testing team. My philosophy is that testing should be a shared responsibility between testers and developers in every software project. Even if the developers on your team are not responsible for writing automated test scripts, there needs to be an understanding on both sides for ensuring quality software.

Testers are in the perfect spot to help significantly with this. By talking with developers and offering sufficient detail and clear expectations to bug reports without providing solutions, you can guide the team to less friction and better software in the end. That's a goal that everyone wants to achieve - testers and developers alike.