Communication for Software Testers

In todays Coders Guild session lead by Scott Kenyon we delved into the topic of effective communication.

Communication is essential to to pretty much any role, and is key for testers. Testers need to be able to communicate effectively to share the bugs they find with team members/audiences with very different backgrounds, e.g. technical / non-technical and as such need to tailor the delivery so that their points are clear, understandable and relevant to the other party.

So say when discussing a bug with a developer and a project manager, with the developer using technical language would be appropriate and helpful in the aim of finding the root cause. When discussing with the PM, the level of technical language may need reducing, and the focus may change to communicating the level of priority the bug needs and the estimated time to resolution. Testers also need to advocate for any tests they want to run and put across the relevance and benefits to the team.

At the start of the session we covered general types of communication and listening, and considered some methods to maximise their effectiveness. This included:

• Effective Listening - have you explained so that they can they repeat it back to you?

• Active Listening - this has many parts: not interrupting, reaffirming/ paraphrase to check and show your understanding - show support and your engagement verbally and non-verbally - and asking open ended questions.

We next moved on to the Communication Contract (in testing)

Communication Contract

• This is Scott’s formula for communicating well with his team :

  “As a tester I’m gonna have a verbal contract with others”

  and this has three key areas:

  • Clear communication

  • Trustworthy/honest

  • Has integrity i.e. if you say you will follow-up within the day - do it!

    He had a great example from his workplace with the transition to remote working in lockdown. He was finding that emails back and forth and quick zoom calls were not an effective way of communicating with one of the devs he was working with. So they discussed and agreed to be on a continuous zoom for 3 hours of the morning, on mute until they had a thought to share - and this style really helped them to have great communication despite the challenges of being remote. It shows you won’t necessarily communicate with people doing the same roles in the same way. It’s important to have that open and honest dialogue if the current way isn’t working and ultimately that can be rewarded with better communication trust and cohesion in the team - a win all round!

Investigation Models

We then moved onto structuring our feedback. While ‘constructive critisicm’ is a term we all know well, and know how valuable it can be to receive, I’ve realised I’ve never actually come across any methods like these before.

First up was the “5 Whys” investigation model. As testers we should be inspecting and inquiring about everything that is put in front of us. This model uses counter measures - actions that seek to get more information until there is a fully formed answer. It could be used in a demo of some new functionality or software - when spotting something unusual, keep asking why until you get to the root of the issue

However, in the now prevelant situation of remote working it is likely as a tester you would instead be handed the software with documentation to start working from - and so may not have an opportunity to ask your questions before starting testing.

So how can we handle this scenario?

Feedback Models

These can be followed verbally or in writing, e.g. they could be integrated into a Session Based Test Management Template.

When choosing a model to work with, considering factors such as what is the situation, why is the feedback needed, what stage in the cycle it’s being used at, and who it’s for - can help to select the most useful.

Broadly, they help remove any bias you have by guiding you to only consider what you can see, to provide an explanation of what does not seem as expected, and finally to express the potential impact, and any obvious strategies to mitigate the risks identified.

DESC —> what you would like to happen, based on what you see

• D - desribe what you are seeing happening - make no assumptions!
• E express the impact of the behaviour on someone, how it makes you feel - e.g. for customer it isnt a logical route, or good UX
• S specify - pinpoint what is different in what you see to what you expect - how it doesn’t meet the requirements expected
• C consequences - what would be the impact if this feature went to production?

Dealing With Conflict

At some point it is likely that there will be pushback against your feedback, and it’s important to handle the situation well. There are plenty of aspects you can consider before and during giving feedback that build trust and help avoid and de-escalate conflict.

Before:

• Has this person asked for feedback? This can impact how in detail you may want to go, if they have it’s depth is good, and also making sure it is delivered in. If they haven’t, consider if they mind you dropping in to talk something over unexpectedly or whether they prefer to schedule times and to know in advance.

• How critical is the risk? Consider how promptly this needs to be brought to someone’s attention and resolved. Does it require urgent consideration or is alright to schedule for a later date.

During feedback:

Ultimately, you want to maintain and build a good relationship with the recipient and overall establish in the feedback process - you’re an ally not an enemy!

• Balance the positives with the areas for improvement, giving recognition of what’s working really well shows you understand the work and puts any recommendations for improvement in context

• Depersonalise - Focus on the behaviour of the software being reviewed without bringing in who wrote it, helping avoid any feeling of being “blamed”

• Non-verbal communication - making eye-contact as you speak and keeping your body language open and friendly helps to create a relaxed environment and

When experiencing pushback:

• Stand your ground - assertive communication can be polite but shows that the conversation is not going to be stopped through their resistance, for example using ‘I’ statements , keeping eye-contact and maintaining open friendly non-verbal communication

• Be an active listener, show you are listening to their response, give them time to finish their points and ask questions to dig deeper into what’s being said - it may reveal new information which leads to…

• Don’t think you are right! - It can happen that what you’ve been working from, doesn’t give an accurate view of the software, and it turns out your bug doesn’t actually exist. Practising depersonalisation from ‘your bug’ helps you as a tester in turn to not be defensive and reach the bug free happy ending everyone wants!

Still getting nowhere?

• It is ok to walk away (for now), if the discussions have become unproductive. Having time away to cool off and rescheduling can allow everyone to come back together, calmer and having collected their thoughts on what needs to happen next.