How I used communication to overcome 4 challenges as a test automation engineer

Last updated: July 2021

Audience member raising their hand to speak

TL;DR

  1. “Why do we need a test automation engineer?”
  2. Presenting a solution to enhance an existing process
  3. Asking for a raise 💰
  4. Telling a team member their feature is flawed

Introduction

I’ve been mainly working with fully remote teams — check out my article on building (a real) team during the pandemic — for these past few years. And, although I love working remotely, some communication struggles have been getting tougher to workaround in a virtual and remote world.

In this article, I‘ll share how to approach some of these common communication struggles with examples.

How to communicate better to solve common challenges

1. “Why do we need a test automation engineer?”

My first reaction be like, who doesnt know what the heck does being a test automation engineer even mean? But, reality check: The majority of the clients don’t have a clear definition nor understand the need for a test automation engineer that they’re paying for, and that’s ok.

The critical factor here is to know your audience. Whenever you’re communicating, whether verbally or in writing, you must know who it is that you’re communicating with. Thus, if you’re communicating with someone outside of your domain of expertise (e.g., a client, a product manager, UI/UX designer, etc.), you shouldn’t be using acronyms or referencing concepts, tools, or technologies that they’re not going to be familiar with. That will merely make you lose them in your speech, and sometimes they’re going to tell you that, and sometimes they’re not.

Therefore, reply to the question in such detail that they fully comprehend the value that they’re getting by having you in their team. Examples:

  • Cheap — You need a test automation engineer to ensure the product’s quality.
  • Detailed — Although quality is the responsibility of everyone in the team, I am here to enable, guide, and ensure that everyone lives by it. For example, here’s data demonstrating the number of issues we prevented before releasing by having a robust automated testing suite integrated into a fully automated pipeline. Thus, having me as a test automation engineer in the team allows us to develop and deliver our product faster and confidently to the world.

Friendly reminder, note that knowing your audience also applies when you’re talking to a peer of yours who is not at the same knowledge level that you are (e.g., talking to a brand-new team member about parts of the codebase they don’t know yet). On the other hand, this is also applicable when talking to someone with a higher level of experience. Make sure you don’t lose track of the goal of the conversation by going into too much detail in regards to things they already know.

2. Presenting a solution to enhance an existing process

You’ve got a dozen of brilliant ideas a minute. However, when given a chance to present them, you’re often caught with the feeling that you left the meeting and not everyone is on the same page nor as excited about them as you are.

The chances are that you didn’t provide enough information nor weren’t clear enough, or didn’t give everyone in the room space to reflect or ask questions they might have. Therefore, favor overcommunication instead of under communication.

Overcommunicate can mean going into more detail, giving more information, or repeating yourself how many times to ensure complete clarity. This applies both verbally and in writing. Examples when ending a meeting where you presented a solution to enhance the delivery process:

  • Ineffective — Now everyone knows the bottlenecks in our delivery process and the solution to solve them. Thank you for attending this meeting.
  • Valuable — To summarize, we’ve talked about our delivery process and its bottlenecks. These are our main issues (…), and this is how I believe we could solve them (…). Which, in the end, will result in a 10x times more efficient process. Does it make sense? Does anyone have any questions? (…) Also, please feel free to reach out to me at any time for more questions!; here to help. Thank you for attending this meeting.

But remember, focus on understanding the questions that the audience needs an answer for rather than providing answers for questions they didn’t have in the first place. When they’re asking questions, you are the audience; thus, if you didn’t understand a question, ask them to clarify.

3. Asking your manager for a raise

There are conversations where you know your audience, but you can’t simply overcommunicate, and 100% want to leave as little room as possible for further questions. Such as asking for a raise — the first time I asked for a raise, holy moly macaroni, I was shaking.

The best way to prepare yourself for such serious and critical conversations is to structure your communication. Present the context or thesis of what you will talk about at the start, then follow up by describing the subject and finalizing the expected outputs, a summary, or a conclusion. Examples:

  • Thesis — Hey, manager Foo. I want to talk about compensation. Do you have a couple of minutes?
  • Description — I think I’m underpaid. I’ve looked into the data online and talked to my peers. Here’s all the data that I found (…). In addition, here’s a list of all my achievements for the past couple of quarters (…).
  • Conclusion — And therefore I’m requesting a raise.

Asking for a raise may be daunting, and it may not get any easier over time. But, if you prepare yourself with a proper structure, and on top of that, you back yourself up with data, you’re golden 💰🏆

4. Telling a team member their feature is flawed

Whether you’re a tester, a developer, or a product owner, there’s going to be a time where you’ve got to tell a peer of yours that the feature they worked on for how many hours is flawed. You’re criticizing people’s work, and this is a sensitive subject.

As test engineers, we’re the ones doing this the most amongst our peers. It is particularly crucial to be aware of your intonation when communicating such feedback — it is what you say, but it’s also the way you say it.

Your voice is an incredible instrument. Use intonation, gestures, and posture to ensure that everyone in the room understands when you’re providing feedback, whether being sarcastic, telling a joke, or being serious.

Although verbally it may be more accessible, intonation in non-verbal communication also needs to be captured in a remote and virtual world. Make usage of emojis, punctuation, and clarify your intentions. Examples:

  • Careless — Hey Joe. The feature you’re working on is not good yet. Check the comments. I am sending it back.
  • Caring — Hey Joe! The feature you’re working on has some issues 🙊🙈 It works, though 🙏 but needs some redoing. I left a couple of comments to guide you. I am sending it back. Let me know if you need anything else from my side.

Be aware that people work truly hard to get their work done. If by any means you feel otherwise, guide the conversation to understand if there’s anything wrong instead of jumping to conclusions. Examples:

  • Awful— Hey Joe. You’re not getting it. It’s still wrong.
  • Exceptional — Hey Joe. I’ve noticed that the feature you’re working on is still not behaving as intended. Is everything alright with you? Any blockers? How can I help you? 💪

This actually happened to me, where I was going back and forth with a feature with a peer of mine for quite some time. But then I asked, “Is everything alright?” instead and it got us to talk about some personal issues of theirs. Fate or no fate, a couple of days went by, and the feature came in flawless ✨

Conclusion

On top of such a remote and virtual world, as modern and agile test automation engineers, we’re now communicating more than we were ever before.

Suitable communication is more than a soft skill. It’s a tough skill that may single-handedly make you exceed within your professional path. And, like any other skill, you can master communication.

Nonetheless, keep in mind that people work hard for their goals, but we all have our bad days (check out the article on the dark side of being a test automation engineer). Thus, take these examples as a piece of sharable knowledge that you tweak and apply according to your personality, occasion, and taste while respecting and caring for your peers.

Clap yourself if you read it all. You’re a champion.

For more articles like this one, you can follow me on medium and Twitter. We can also have a chat on LinkedIn or share some code on GitHub. 🤓

Use the link above ☝️ to sign up to my network as a freelancer or to hire talent. We both win a bonus of up to $2,500 💰
If you have any questions, please feel free to reach out to me on LinkedIn.

Hey, my name is Sérgio and I’m a Test Automation Engineer by trade. Here you’ll find short and straight to the point articles related to my craft.