We’ve all been there. Developers aren’t listening when you tell them the severity of the problem; you’re repeating the same status over and over to the same people; you accidentally commit to a timeline or project that you can’t possibly complete. Communication in Testing is key.
This is the time where I will let you in on a truth that if you faced one of the above situations or something similar, you may be a tester who puts in lot of effort into your work but fail to communicate your ideas in an understandable and precise manner. These are all common communication issues, shared by many software testers around the world. Now you may ask yourself – “Why is this a common occurrence among testers?” Let’s spend a moment to highlight some things that leads to this situation.
Testers often fail to realise that they talk to different audiences on a daily basis. They talk to project managers, business sponsors, developers, solution architects, domain architects, other testers, requirement analyst and so on…. The list is never ending. This being the case, are you going to give the same type of information to each and every person? Let me give you an example to give more clarity on this.
Say you bought an old house that needs lot of repairs to be done. You have repairs related to plumbing, landscaping, air conditioning, roofing, heating, kitchen remodeling, carpeting etc. (Yes, I know what you are thinking, selecting this house was a bad choice to start with!). Now, you call a plumber to your house – what type of conversation would you have with them? Would you talk about the problem with carpeting, heating, roofing and landscaping? Of course you wouldn’t. When you talk to a plumber you talk about problems related to water leakage, draining, and any other problems related to plumbing. Similarly, if you call a landscaper, you would talk about the lawn, grass, flowers, and decorative stones in the backyard and so on…. Although you have different repair work in your house, you talk about the specific repairs he/she cares about, not the whole picture every time.
This is the same case with testing too – it is important to know your audience when providing information.
For example say you want to provide information about a critical showstopper defect you found. The information you provide about the defects varies based on the audience.
- The Developer would be interested to know what systems are getting affected due to the defect and any information related to other systems
- The Business Analyst would be interested to know how this defect is going to affect the customer experience. He/she needs information related to the number of customers being affected and the impact to them.
- The Project Manager would be interested to know how the showstopper defect is going to affect project schedule. The project manager would have to make changes in the project schedule and estimates accordingly.
Know Your Audience
Thus, it is really important to pay attention to what type of information you give to what type of audience. The first lesson here is Know Your Audience.
When providing information to your intended audience, make sure you prioritise your points. In the house-owner example, if there is water leaking in the kitchen and is flooding throughout the house, this is probably the first information you want to communicate to the plumber instead of talking about replacing old shower heads with modern ones in your bathroom.
Prioritise Your Points
Similarly when providing information through status reports or bug reports, make sure you provide the top 3-4 points you want the stakeholders to know; this is what I call headlines. Just like how a news reporter first gives the top headlines of different things happening in the world to the viewers before getting into details, the tester gives the headlines on testing progress, about the top 3-4 items the stakeholder needs to know before expanding on each item. So, second lesson here is Prioritise Your Points.
Often testers fail to realise that there is another important factor called communication patterns to consider when providing information. I classify communication pattern into 3 types.
Formal and Informal Communication
Formal communication is when there is some sort of structure involved when providing information. This includes group meetings, business meetings and stand ups.
Informal communication is when there is no structure involved when providing information. For example, walking up to your developer and asking him to explain a feature in the system or walking up to your requirements analyst and asking her to provide more information about a particular story card. So there is no formal structure involved when getting/providing information
Face- to- Face Communication
There is considerable amount of communication that testers have to do face-to-face with other people. When doing this they have to be aware of the following things to make sure he/she understands the information you are providing.
Body Language
I have had many situations where I was providing some information to the developer, while he is playing or texting on his phone; I’ve also seen situations where testers go on and on about a defect they found, thus leading the developer to get lost in information due to information overload.
The below points may help to be aware of your body language
- Show interest in the discussion
- Try to understand the full story before reacting
- Be engaging
- Maintain proper body posture
- Maintain eye contact
- Give clear, concise information
Facial Expression
Facial expressions tell you a lot about a person’s understanding. Are they just nodding their head since they want to get rid of the other person quickly, or do they have a blank look, meaning he/she doesn’t have any clue what you are talking about but are too proud to admit it?
Pay attention to facial expressions of your audience when communicating, as they will help to immediately show whether you are heading in the right path or digging yourself into a hole from which it will be hard to recover.
Social Communication
It is really important to get to know your team members on a personal and professional level. You will be amazed by the power of social communication as it make a testers job so much more easier when you actually know a person, rather than just talking to him when you only need something.
Recognise Communication Patterns
Make sure you meet your colleagues outside work at restaurants and team events to get to know your team members on a personal level. Once you start doing this, the next time you are stuck with a problem or need help, people will be more than willing to help you out even though they may not be directly related to what work you are doing or the system you are testing. Kind words and simple expressions such have “How are you doing today?” “How did your kid’s birthday party go?” goes a long way in establishing rapport with your team members.
So, third lesson here is Recognising Communication Patterns
The fourth factor which hinders our job as information brokers (a tester’s task of providing valuable information about the system which would aid decision making) is not being able to understand cultural differences.
Have you ever worked with teams who are in different regions of the world and you have to remotely communicate with them? Have you ever been in a situation where you communicate something to the remote team and they provide you something which is totally unrelated to what you actually asked for? I was one such tester who was in this situation and it thought me a lot of things about working with teams in other regions of the world.
You think that you have no problems like the above? Here’s a simple exercise to prove my point. What is wrong with the below e-mail communication between an American manager (George) and Chinese Tester (Chang)?
Hi Chang,
Can you please make sure I get the status reports on January 31st?
Regards,
George
The odds are George is never going to get the status report on January 31st. Why? This is the Chinese New Year which is a national holiday in China and many parts of the world. It is very important to recognise these cultural differences when communicating with remote teams.
Understanding Cultural Differences
So, if you are working with a remote team, please put effort in an extra effort in trying to understand their culture and region. This will go a long way in building a good relationship with your remote team. This leads us to the fourth lesson of Understanding Cultural Differences.
Finally, we come to using Safety Language. Let’s start with an example-
Analyze the difference between the below sentences
“It is going to rain today”
“It might rain today”
Say you are using a weather app on your phone. It says “It is going to rain today”, so based on this information you prepare for rain, dress accordingly. When you come out of your house, you notice that is sunny, hot, and humid and there are no signs of rain. What would you think about the Weather app you used now? Will you trust it in the future? You may probably trust it once or twice and if it still gives you wrong information the odds are you uninstall the current weather app and install another competent weather app which can give you the right information.
What if the weather app had said “It might rain today?” or something like “Chances of rain is 30%” Then, you may have just taken an umbrella with you instead of going the whole nine yards of preparing for a rainy day. When you come out of your house it is still sunny, hot, and humid and there are no signs of rain. You may just say “Oh well! It is not raining now but I will just take my umbrella instead” and you will go your merry way. Once you get a slight drizzle of rain, you will feel happy that you brought your umbrella with you. Again, this is a very hypothetical example to highlight a point that the same is true for testers.
As a tester you are often caught by surprise and forced to commit to something that you have no idea about, you don’t have time to finish, or you are not sure whether you are the right person to do the task in the first place. How often have you been in a situation where your project manager puts you on the spot and makes you commit to something that you later repent that you should have never have done it. (Remember the manager from the movie “Office Space”)
During situations like this, you can use safety language to keep yourself from getting trapped. So try to use phrases like the ones shown below to have control of situations at all times.
“It appears to be a picture of…”
“It might fail under these circumstances”
“It appears to fail”
“You may be right”
“I might disagree with that”
“I’ve noticed that…”
“My experience has been..”
So next time when someone asks you “In which scenario does the system fail?” you probably want to think twice and start your reply by saying “The system might fail under these circumstances……”
There you go, these are the lessons I learnt and I hope that they help you with your communication in Testing. These lessons made me an effective communicator:
- Knowing your audience
- Prioritizing your points
- Recognizing communication patterns
- Understanding cultural differences
- Using Safety Language
