The path to effective communication for software testers

A 5 minute read written by Tallitha June 17, 2015

An illustration of two speech bubbles with smiley faces in them. One smiling, one with a neutral face.

Imagine that you’re booking a flight to Paris. If you don’t pay attention to the specifics, you might find yourself on a flight to Paris, Texas, instead of Paris, France. I’m sure you’d agree that those little details are essential.

It’s an example of how poor communication, especially when you’re not speaking to someone face to face, can cause confusion – and you might end up eating BBQ instead of a croissant.

Communication (noun): the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs.

Communication is one of the most important soft skills a software tester can have. Communication between testers and developers is crucial, and it is definitely the key to successful projects. Poor communication can lead to misinterpretation, impact productivity, and cause a lot of rework, especially when reporting defects and working with remote teams.

Yes, we’re all busy, but it usually takes more time to write a bad, defective description than a good one. Why? Initially, it can save you time when describing the problem, but it can create extra effort for you later on. Today I’ll show you how a small process change that helped us facilitate communication between our team members.

Keep information moving forward

It’s very common to have quality assurance (QA) team members working across different team projects. Here at Yellow Pencil it’s not different. The QA members work on more than one team project at a time with different individuals, different clients, and different technologies. It’s very important to communicate effectively when reporting a defect; otherwise the person assigned to fix it will likely ask you for additional information or instructions on how to replicate the problem.

What seems like a simple act can actually delay progress, and all those little delays can add up to a lot of wasted time. It’s worth entering all the necessary information on a bug report while everything is still fresh in your mind, no matter if you are a developer, a UX designer, or a tester.

Keep in mind that in a fast-paced work environment it’s typical for people to leave or join project teams. When that happens, the work should continue moving forward and whoever gets to work on bug fixing needs to understand what the actual problem is — and quickly. The person who had submitted the bug may be on vacation having a joyful time eating a croissant in Paris (or BBQ in Texas) so it’s probably not a good idea to call her asking for further instructions such as, “I can’t replicate this bug. In which environment did you find that problem?” Investing time writing a good bug report is a time-saver.

5 steps to writing a rock-solid bug report

We have created a basic template to guide us in reporting bugs. It’s very simple, efficient and widely used in the world of QA. But first, here’s the foundation for writing a rock-solid bug report, following five essential steps:

  1. Be specific: Clearly summarize what the problem is – get straight to the point.
  2. Be descriptive: Include every single step to reproduce the problem; add screenshots.
  3. Be focused: Pay attention to what really matters – the actual problem that needs to be fixed.
  4. Be organized: Report only one problem at time. If there’s more than one problem related to the feature you’re testing, split them into separate issues so they can be quickly fixed and tested.
  5. Take time: The title or subject is very important when triaging defects because it helps to instantly identify what the problem is without getting into details. So take time to write something specific; it will save you time in the long run. For example, saying that “the system is not working” is very vague and does not give developers enough information to help find the root cause in order to fix the issue.

The steps to reproduce the bug are meant to be “baby steps” so anyone can easily replicate the problem. If you can’t reproduce the problem by following your own steps, how will anybody else?

Here’s the template:

And finally, a real example of a completed bug report:

Say what you mean — and get what you want

Getting to Paris, France instead of Paris, Texas involves investing a little time into finding the right flight code, and you can already imagine the benefit of making this extra effort. Investing time writing a good bug report isn’t that different. After all, it’s the main communication channel between the QA and development teams. It might seem like a lot of effort at first, but every second spent on that task will save you a lot of time down the road. Not to mention the productivity and high quality of the deliverables on your project team. There’s a huge chance of getting the things done faster and without any misunderstanding or rework. So say what you mean to get what you want.

Want to learn more about writing rock-solid bug reports or communicating effectively with QA teams? Have some tips of your own to share? Get in touch or leave a comment below.