Extraordinary testers are those that can empathise with their team members
As testers we ultimately want to help other people prevent problems before they start manifesting into some unwanted behaviour of a system. That is the dream! However, it’s often the case that we discover problems. If we can understand some root causes of problems, then we will be able to prevent more problems and curing (fixing) less.
One problem that I want to explore in this blog post is team member inexperience in product, technology or code. There is naturally talk about empathising with our customers, but one conversation we need to highlight is how we need to empathise with our team members.
I don’t have a statistic for you, but I bet a fair amount of bugs are caused by a team member’s inexperience with the product, technology or code.
We are humans! We are not perfect and make mistakes.
This quote is important because it’s completely true. I know of course that we want to put our best foot forward at work, but mistakes happen by all of us. The key to mistakes is that they are fine as long as you are learning from them. It becomes problematic when you are making the same mistake time and time again.
Two ends of tunnel — safe or blame?
I have worked in teams where team members have been very open with what they know or don’t know. They explicitly call out that there is a risk here because they are new to this area of the product, code or technology.
On the other end, I have seen team members blame each other for a production bug. Oh the developer should have picked this up, or why wasn’t this tested? This scenario is horrible to be in. This is where managers can come in and squash this. Managers need to do everything they can to push the scale to that psychologically safe environment where you can talk about the risks openly, rather than a pointing finger environment. This is where test managers add value, to change the environment, so that everyone can have their right to speak and be open about matters.
Be aware of “lack of experience” problems
What I want you to do is be aware of problems created by a lack of experience in product/technology/code! Your team members are not perfect and will make mistakes. This goes to all people in your team, whether they are testers, developers, product owners, UX etc.
Have courage and ask questions
The second thing I want you to do is have courage and ask probing questions to your team.
- How are we feeling about working on this legacy area of the product? What are the risks? How can we prevent problems?
- What about this legacy area of the code? What are the risks? How can we prevent problems?
- Or how do we feel about working with this new tech? What risks are there? What can we do to prevent problems?
Have your team member’s back!
The third thing I want you to do is have other people’s back. One example I can give is where a developer said to me how nervous they were about making a particular change. Tell them you’ve got their back and that you can explore together. What in particular are they nervous about? Could we note some things down in our exploratory/regression testing to make us both feel more confident about the change? Perhaps we need to communicate to the wider team (like the support team) about the nervousness, so everyone can be aware and we can react accordingly if we need to. Ideally we’ll have everything covered, but it’s good to create awareness as back up!
Admit your mistakes
I try to be as transparent and honest as I can. I don’t know everything and I’m always working to improve. In a global conference I openly admitted that there was a time where I didn’t want to do a hotfix because it would affect the metrics. It was a lesson I took away
Metrics are a good conversation starter. Nothing more.
Overall though, if you can create empathy with your team members you’re going to guard against problems that are caused by team member inexperience in the product, code or technology. You’ll also be in a happier team as a result.
Twitter: https://twitter.com/fishoutthebox
