A classic problem for testers in agile contexts is the fact that they feel they are not listened to by developers. Testers, often rightly, warn developers from doing stuff because the consequences could be very bad, but developers in many cases don’t listen to them.
This is very upsetting, testers find themselves lonely within an agile team because of this. They get frustrated and if they keep on asking and screaming their needs they risk being alienated by their team members becoming completely ineffective while growing dissatisfied with their job.
But, but, they are right in telling the developers what to do! WTF?
When working as a tester in an agile team you’ve got to develop a skill that before you really didn’t need that much.
It is called influencing. Before when you worked in your separate QA department/test team you didn’t need it because there was a test manager that was fighting the battles for you and deciding the test strategy to be applied.
Things have changed, you’ve got to become good at influencing.
This is what Gus did when he moved to an agile team as a tester many years ago.
First I tried barking orders, screamed and shouted, but it din’t work at all, so I decided to adopt a different approach.
- I started to really listen to what developers said instead of listening for finding gaps in their thought
- I listened and listened and listened a bit more
- Third I started asking questions showing real interest in what they were doing. Being mindful of their fears and feelings. I made sure they knew I was there to help and that we were all in the same boat
- I started praising them when they did something good, for example thanking them for adding testability to the application. Things like “without Roberto’s design I would have spent weeks doing what I can do now in 10 minutes, thank you so much Roberto, you made my life better”
- I started coaching them on how to test by testing with them. When they saw what testing really involved, they understood its importance and challenges and started asking interesting questions about it.
Who will developers listen to?
Now compare the developers’ reaction when faced with a suggestion raised by Gus to the one that Jack gets. Jack is a tester that uses the classic approach of “what the hell are you talking about? This is going to explode in production!”
Who do you think will be able to influence developers actions when something important for testing needs to be done?
Not Jack.
Me? Often, I always got the developers at least to listen to me and a lot of the times we did it my way unless somebody in the team had a better idea.
So, do you want to be Jack and keep on moaning about developers that don’t understand anything about testing?
If I were you I’d take Gus’s approach and build your influence within your team, start now, start listening.
| Reference: | 5 Easy steps for Testers to Influence Developers from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
