In theory, we’re all supposed to be on the same page. In the quest to deliver stable builds that excite end-users:

  • Software testers are in charge of finding and reporting bugs.
  • Software developers are responsible for fixing those bugs.

It all sounds pretty straightforward.

But the reality is often very different.

There are times when developers don’t devote as much attention to newly discovered defects as they should.

These oversights aren’t entirely the developers’ fault. After all, they receive tons of defect reports throughout the day – every day. Some bugs will inevitably fall between the cracks. And there are other mitigating circumstances that sometimes slow down the process further, including:

  • In-house priorities set by the team manager.
  • New feedback and directives from the client.
  • Stress, tight deadlines, and insufficient time.

But no matter the cause, the final result is still the same. You’re left with a buggy product that isn’t ready for primetime just yet.

So how do you (as a software QA professional) get your developers to fix leftover bugs – and fix them with a smile?

Unfortunately, there is no magic formula. But below are some best practices that might deliver the results you’re looking for.

1. Defining Goals and Objectives
The first step involves making sure that everyone is familiar with the requirements and scope of the project. Team meetings and brainstorming sessions can help. But the real focus should be on your own understanding of what is expected.

Only then can you move on to the following steps.

2. Removing Guesswork and Confusion
When reporting defects, it’s important that you submit the clearest and most helpful bug reports possible. This should include all of the individual steps needed to recreate each defect. And it never hurts to throw in screenshots.

But for the best results, we recommend using screencasts. Nothing will make your developers’ jobs easier than providing them with handy videos that reproduce bugs in real-time. This helps to remove confusion since:

  • Developers no longer have to read long descriptions.
  • They don’t have to guess or “interpret” what you mean.

Defect videos also help to remove friction since you’ve already done most of the heavy lifting. Developers can see the who, what, when, where, and why of every bug you report. And instead of reinventing the wheel from scratch, they can focus their full attention on cleaning up the problem areas that you’ve already singled out for them.

3. Respecting Their Time
Remember that developers receive lots of defect reports throughout the day. So don’t send your own bugs if you haven’t already reproduced them at least twice. There’s no reason to bring in the cavalry unless it is absolutely necessary.

Along similar lines, don’t reopen a “closed” or “resolved” defect without sufficient proof that it needs to be revisited. Fixed bugs don’t require further attention. And reopening them implies that the developers aren’t doing their jobs correctly.

Don’t open a “closed” or “resolved” defect using a different configuration, environment, or platform. Instead, open a separate case and mention the original defect.

And finally, refrain from sending duplicate reports. If you clutter up your developers’ to-do list, they’ll be more likely to ignore future reports from you.

4. Making Consistency Central
Don’t you hate it when TV remote control buttons are in “nonstandard” locations? Or how about when light switches are a little higher or lower on the wall than normal?

Consistency is important. And the more standardized you can make your bug reports, the better:

  • If all UI comments are in the same section of each report, this makes it easier for developers to attend to those bugs all at once.
  • The same is true when reporting back-to-back defects pertaining to the same few lines of code. They know precisely where to look. And they can potentially fix all “related” bugs in one single session.

5. Becoming a Better Communicator
As a software tester, you must accept that there are things beyond your control. And ultimately, you must trust the developers to do their job.

However, you can facilitate that job through better communication and feedback.
This is much easier to do when working in on-site teams than when working remotely. But one simple strategy you can adopt involves talking to your developers as if they were living, breathing people (because they are).

  • If you work in the same office, walk over to their desks and get to know them.
  • If you work remotely, engage with them over the phone, in video calls, and other more-personal-than-email options.

The exact approach doesn’t matter. The goal is to develop professional rapport with your fellow teammates. By treating them with respect and civility, they’ll be more inclined to do the same. And future bug reports won’t spend as much time in “limbo.”




Have you discovered any better ways of making sure your bug reports receive the timely attention they deserve?
If so, please share your experiences down below.