Effective communication between software testing teams and management helps us to avoid confusion and mistakes. Here are some tips to help us to improve.
How often have you thought your managers speak an alien language, or they just don’t get what you’re talking about? Instructions and messages can feel like they’ve got lost in translation, leaving you to do more work (or worse, redoing work) because of confusion. Perhaps, in your frustration, you think that other departments and team leaders must be a bit stupid because they can’t seem to grasp simple concepts?
But have you considered that the problem might not be theirs entirely? Communication works both ways, and in our busy industry, ideas and instructions can become diluted or misinterpreted, and possibly even more so due to remote working. Sometimes the original message is unclear or maybe not crafted with the care needed to be understood by all parties.
How can software testers and management learn to speak the same language?
Let’s take a look at a few practical suggestions that can help us all to better communicate with each other.
Put yourself in the other person’s shoes
As a software tester, it’s fair to assume you’re pretty tech-savvy. While you won’t have all the development skills and knowledge of those who build the software, you intuitively know your way around an interface and probably have a basic understanding of how systems work “under the hood.” So when you are communicating with management and people in other departments not within the technical sphere, it’s useful to remember that they don’t live in the world of software development. Their primary focus is likely to be managing people and deadlines, approving roadmaps, and appeasing other stakeholders who may be giving them a hard time.
While they only need a basic understanding of what you do and how that works, it would be helpful if you could cut them some slack and appreciate how they will only dip into your world but, it’s yours to live and breathe every day. Likewise, if you could have a basic understanding of their role and its pressures, you will find that it’s easier to meet each other halfway. Which brings me to the next point…
Communicate using human language – no jargon
I’ve worked in many teams and helped various businesses and organizations during my career, and there’s one thing they have in common – acronyms! We all love acronyms, abbreviated terms, and product names. They’re catchy, easy to remember, and – based on their prevalence – must clearly save us hours in time because saying the whole thing would be a poor use of our productivity!
Remember also that just because your department or pod are fluent in what these terms mean, your managers may not be. So don’t risk having to explain every acronym or piece of jargon to them. It’s probably quicker to use the full term when you document your work, write emails, or communicate on Slack, and in person.
There is no such thing as a stupid question
The quality of answers is based on the quality of the questions posed. If we want to get to the bottom of something that we don’t understand, don’t be afraid to dig a little deeper and ask, even if it’s something you might think of as “a stupid question.” There was a time when the person you are asking didn’t understand either.
People we encounter day-to-day in software testing and development-life all have their own assumptions and blind spots. Your manager might assume that you know something simply because she knows it. It might be evident to her and imperative to her role, so don’t feel shy in asking. It’s the manager’s role to clearly explain things to you when giving instructions or updating you on a task. Likewise, if somebody outside of the development bubble asks “a stupid question,” realize that you too have your own assumptions and blind spots, so be patient when explaining things that, to you at least, are evident.
Cultivate a no-blame culture
During the more than ten years that I have been working in design studios and with development teams, I have seen no end of things go wrong, from little bugs that were missed to huge missteps and bad ideas. Some of these have been bad enough to knock an entire product off course, missing release dates. There have also been some painful conversations with the board along the way.
When things go wrong, as they inevitably will at times, it’s essential to try not to play the blame game. It might be a natural reaction or survival instinct to say, “but that’s not possible,” “I didn’t do that bit,” or the classic “It was like that when somebody else delegated it to me.” Short-term weasel-tactics like these won’t help the team in the long run, and this type of thinking will lead to your undoing in the future as people start to realize that you’re not a team player, or worse still, you are untrustworthy.
So next time it hits the proverbial fan, take a breath, reflect on what has actually happened, and say something like, “Some of the responsibility for this is mine. I recognize it needs fixing and will do what I can to make it right.”
Take notes
When being briefed on a task or if you are part of an important meeting where tasks are being delegated, it’s usually a good idea to take notes or summarize the meeting’s actions and outcomes. Notes are useful for referring to later – after your brain has processed a million other things between the end of the session and the time to start on the work. They are also useful because the act of writing things down can help you to remember things better.
By having a list of actions and outcomes, especially if they were given to you by a manager, you will be able to refer to them at a future date if any misconceptions or misunderstandings crop up about the scope of the work required. Always keep your receipts, so to speak!
Make use of systems and software
You probably have a long list of tools and software that you use, and as someone who works in software, you probably have your favorites as well as the ones you despise but have to use anyway.
A few great tools that I use and have had recommended to me by software testers and development experts are:
- Trello – A great visual tool for tracking a project’s progress and organizing tasks, either alone or connected with your team
- Asana – A fantastic project management and communication platform
- TestLodge – An excellent tool created for software testers to manage and automate their workflows
Whichever tools you use, remember that using them to communicate with your managers and teammates is important too. Remember to write your updates clearly, plus any outstanding elements or issues you encounter that need raising or addressing. Keep lines of communication open with your team. When using these tools, it’s useful to tag and delegate tasks to those who need to look into things, then follow up after a day or two.
User stories – use them in your conversation
When we start designing or testing a new feature, we need to have a clear understanding of the feature’s purpose. If the app has a feature where the user can drag an item from one list to another, sharing just the basics of what needs doing might not be detailed enough to explain what it really does and why your user needs to do it. So when creating a task for someone to work on, or when talking to your managers and wider team, it’s essential to use the methods of user stories explained in your everyday language. If you’re unfamiliar with the term, you can read this article about user stories. Briefly, it’s about reframing how you describe something by wording it to read like a narrative of a user interacting with the interface or software. A user story quickly identifies the user type, identifies the action taken, and explains the desired outcome. For example: “as an admin user, I want to drag my list items from one box to another, so I can track the process of the items.”
Using this format when you communicate with your managers and people outside of your software testing and development department will help them to understand why you’re doing something, who you’re doing it for, and what the outcome of the task will be.
Summary
We are all on the same team, even if we work in different departments with different goals. While we might not all speak using the same terms, acronyms, or levels of expertise – and other teams can sometimes be frustrating when they don’t seem to appreciate the work that goes into what we do – it’s essential to realize that we can help shape the outcomes of our conversations and assist people in understanding our perspectives and goals if we try. Most people are willing to listen and learn, and a little bit of effort on both parts can go a long way!
We are all on the same team even if we work in different departments with different goals, even though it can be frustrating sometimes when other teams don’t seem to appreciate the work that goes into what we do. While we might not all speak using the same terms, acronyms, or levels of expertise, it’s essential to realize that we can help shape the outcomes of our conversations and assist people in understanding our perspectives and goals if we try. Most professionals are willing to listen and learn, and a little bit of effort from both parties can go a long way!
