Communication is important in any career or area of life. But in the world of QA, it’s even more essential. Testers have to communicate with people at all roles and levels of the company. And on top of that, QA is at the front line when it comes to finding bugs and user experience issues — all of which need to be communicated well. It’s hard to understate the importance of effective communication skills for QA testers.

Read on to find out how to follow best practices for communicating anything and everything as a QA Engineer.

Communicating BugsQA Communication Skills (cartoon QA tester holding a bug report and a pencil)

Writing bug reports alone requires all kinds of communication skills. (Learn more about Best Practices for Reporting Bugs.) But even after you’ve created a bug report ticket, the bug-related communication doesn’t end there. It’s also good to follow these practices:

  • Sound the alarm for showstoppers. A showstopper bug means that it must be fixed immediately. For example, maybe the mobile app is crashing every time a user logs in. When you spot something like this, you’ll want to go above and beyond filing a bug report ticket. While that should be your first step, once you’ve done so, it’s time to make sure your team is aware. Even if you assigned/tagged people on the ticket, they may not have seen the email notification right away. For bugs at this level, it’s a good idea to Slack or call whoever is in charge of prioritizing/fixing it after you create a bug report.
  • When in doubt, file a ticket. Let’s say you notice what seems like a minor issue (or area for user experience improvement). You might figure that your daily standup meeting is a good time to ask whether or not your product manager wants a bug ticket for it. But not having a written record of this can backfire. People have short attention spans – especially when looking to place blame. Someone might tell you to forget about the issue, and that it doesn’t matter. But when a higher-up asks about it later, the same person might come to you asking why you never found the bug. It’s best to have a policy of writing up any potential issues as bug reports. If a manager decides they don’t want it addressed, they can simply delete the ticket or move it to the backlog. (For more about bug tickets, see our guide to the Jira QA Workflow and Best Practices.)
  • Customize your communication. If you’re describing a bug to a developer, you’ll want to provide as much technical detail as possible. Communication between QA and development tends to get pretty in-depth. But if you’re telling a project manager, you may want to give more of an overview.

Email Etiquette

Emails may be a little less frequent these days, as more companies transition to using tools like Slack for the majority of their communication. But it’s safe to say that emails won’t be going extinct anytime soon. And while they’re simple to send and receive, a surprising number of people don’t always practice the best email etiquette. In order to optimize your own, you can:

Effective QA Communication (cartoon QA tester reviewing a tablet app)

QA test important emails.

You can perform QA testing on your email drafts, just like you would with a mobile app or website. This may sound silly, especially if your work-related emails are mainly casual messages to developers. But if you’re emailing higher-ups or current or potential clients, a typo-filled email can make you look careless and unprofessional. They might even doubt your QA abilities if they think that you didn’t even notice a glaring error in your own email. Things to look out for before clicking the send button include:

Typos and spelling errors. At the very least, keep an eye out for the red underline below any spelling issues.

Grammar. No need to go back and get your Masters in English for this one, but even a quick re-read can help identify anything that sounds odd.

Names. Believe it or not, it’s not uncommon for people to misspell the name of the person they’re emailing!

Facts. Is everything mentioned in your email accurate?

Content. Are you leaving anything important out?

Paragraphs. Is your text a giant paragraph that could use some line breaks?

Links. If you’re using them, do they go to the right place? If you’re not using any, are you missing some?

Attachments. Iif you reference an attachment, is it actually attached? Did you upload the right file?

Subject line. Keep it clear and simple.

“To” and “CC” fields. It’s common for people to CC the wrong email address, which can be problematic.

Match your tone. If you’re responding to a higher-up or client, it’s a good idea to respond in the same tone that they use. For example:

  • Emojis and exclamation marks. If the person who emailed you uses them, then by all means you can include a smiley face in your reply, or well-placed exclamation marks. But if the person who emailed you used a much more serious tone without either of these, it’s often best to avoid them in your reply.
  • Casual vs. formal. If someone emails you in a casual tone, they’re likely going to be comfortable (perhaps even more-so) with you replying in the same vein, rather than coming across as stiff. But if someone emails you with very formal wording, you should do the same in your reply.

Condense questions into one email. Of course, if you have ten questions over a period of ten different days, then there’s no need to do this. But if you’re in the middle of reviewing something over the course of a few hours, it’s best to send one email with all of your questions. Otherwise, someone may forget that they didn’t reply to some, or see it as tedious to try to keep track of them all.

If it’s formal, send it in an email. When using Slack for everything, some people forget that email is an option. And, typically, the best one for communicating anything formal. For example, if you’re giving notice, requesting a raise, or sending an important document, email is usually a better medium than Slack.

Slack Etiquette

These days, many people in tech are communicating on Slack all day every day. However, not all Slack communication is helpful or positive. Some people may even be perpetuating annoying Slack habits unintentionally. Here are some tips for making sure you’re not one of them:QA Manager (cartoon woman holding tablet with mobile app)

Be straightforward about what you need. When you’re messaging a colleague on Slack, you’re probably expecting it to be more conversational than an email. But you don’t know if the person is at their desk or available to talk at that moment. Therefore, messaging someone simply saying “hey” without context isn’t the best idea. By the time they’re available to respond, you might be busy doing something else and unable to reply.

Instead, it’s best to be clear about what you need, so they can answer with relevant information when available. You don’t need to be blunt — you can (and should) still be friendly. But you can say something like, “Hi! Happy Friday. When you have a chance, can you let me know which iOS build I should test next?” instead of “Hi” or “let me know when you can talk” (which can sound ominous, especially if you’re in a position of authority).

Follow best practices for tagging. For example, let’s say that it’s important for a colleague to see something quickly. If you’re putting it in a channel, you should also tag the relevant person (or set of people). But if your channel message is not urgent or relevant to everyone at that moment, don’t tag “@here.” This can needlessly distract people from their tasks.

Be mindful of what you say in public channels. When you write something in a channel, especially #General, it’s likely that anyone at your workplace will be able to see it. This should be taken into account on multiple levels. First, you don’t want to say anything inappropriate. It’s wise to assume that any higher-up could see anything you say in a main channel at any given time. And second, you want to stay on topic. Each channel has a specific subject, and even #General should only be used for conversations that affect the entire team.

QA Communication and Timing

Timing plays a huge role in the success (or failure) of QA communication. This can include anything from time of day to email response time. It’s important to factor timing into any form of communication, including:

  • Time of day. If you need to have an important conversation or meeting, don’t schedule it at the end of the day. People will be distracted after a long day, with an eye on the clock. If you’re asking for anything actionable, they also won’t be able to start on it until the next day.
  • Meeting schedules. If at all possible, don’t call impromptu meetings. People need time to prepare, and interrupting the flow of in-progress work can really derail productivity.
  • Meeting length. If you’re in a standup, Sprint Planning, or any other Agile QA process meeting, try to come prepared. If you know what you’re going to cover in advance, you can avoid rambling. This saves not only your own time, but countless colleagues’ as well.
  • Email and Slack responsiveness. As the person receiving an email or instant message, it’s generally polite to respond in a timely manner. But this also doesn’t mean you should let Email/Slack run your life. If you’re in the middle of important work, you shouldn’t feel like you have to stop what you’re doing every time you hear a “new message” ding. In fact, you may even want to mute the sound. Finding a balance between being responsive and helpful without hindering your productivity (or sanity!) is key.
  • If you’re part of a meeting or call, try your best to be on time, every time. It may feel like this should go without saying, but a significant number of people don’t take punctuality at work seriously. This isn’t about giving in to a boss’s every beck and call. Being late wastes your lower-level colleagues’ time just as much as any manager’s. And while it may seem subtle, being chronically late – even by just a few minutes – can be the difference between being seen as reliable and worthy of a promotion or not.
  • Reporting problems. For example, let’s say you realize that a QA estimate you provided is not going to be realistic. Or maybe you’re struggling with setting up automation framework. In either situation, you might be nervous about confessing this to your QA manager or team. However, if it’s going to come out eventually, it’s best to be open about it as early on as possible. Otherwise, not only will you look deceitful for having waited so long to come forward, but there will also be less time to come up with a solution.

QA Skills (cartoon QA tester holding a cupcake)Respect

It’s never wise to communicate aggressively or disrespectfully with a colleague at any level. Sometimes people try to find exceptions to this rule. After all, if a colleague makes a monumental mistake, it can have pretty big ramifications.

But even if someone does something bad enough to get fired over, the conversation still does not have to involve yelling, derogatory language, insults, or any form of disrespect. If you can handle workplace conflict calmly and rationally, you’ll also earn a higher level of respect from others. And if you can’t, not only will you leave a bad impression with others, but you may even risk legal issues (or getting fired yourself).

Some other important guidelines to workplace respect include:

  • Avoid bigotry – even in the form of jokes. You may think that a given joke is hilarious, and that it’s “only a joke.” But if there’s any element of poking fun at a stereotype or aspect of race, gender identity, etc., leave it out of the workplace. Diversity in tech (specifically lack thereof) is already a problem, and alienating people from different backgrounds further doesn’t help.
  • Ask rather than demand. Even if you’re the manager, you’ll have a better chance of getting results by treating people with respect when requesting something from them.
  • Seek info before placing blame. If you spot a mistake or think that a colleague might have messed something up, look into the reality of the situation before automatically blaming the person. This will both help you avoid embarrassment if you were wrong, and provide you with fact-based aspects to bring up if you were right. Even if a developer’s code contains a major bug, there are many reasons not to blame developers.

The Importance of QA Communication Skills

Communication skills are important in QA, and work life in general. By following the above guidelines, you can increase your chances of getting a promotion, decrease your chances of reprimand, and cultivate respect from both coworkers and clients.

Need a communicative QA tester for on-demand QA testing services? Find out why we’re a top QA company.