Reading Time: 4 minutes
Why Testers Need to Provide Insight
I recently wrote an article for CrossBrowserTesting on Why Testers Need to Provide Insight. This is something I feel very strongly about, and is inspired from my time working in IT recruitment.
I recommend reading the previous post to understand why it’s so important for testers to start providing insight.
How to Practise Providing Insight
For testers who are used to the confines of test case execution, or are rarely encouraged to use their skills in other ways, the idea of providing insight and finding opportunities to do so might seem alien at first. Nevertheless, many skilled testers may already have this ability, and simply need to feel “freed” to do it.
Here are some tips to get started:
1. Don’t wait to be asked
Any good team member should be able to work on their own initiative. This is especially important when it comes to providing insight, because all the important components usually aren’t easy to find. It takes more digging, different ways of thinking, and exploration to uncover them. Don’t wait for someone else to ask you to look into something – be the one to lead the way.
2. Be aware of your own thoughts, observations and theories
If you’re not used to speaking out, or are just used to having your concerns overlooked, you might need to retrain yourself to be aware of your own thoughts, observations and theories about the project, and any potential issues. Through working intimately with the software, testers often develop a very good instinct about when things aren’t right. Tune into these triggers and use them as a prompt to start investigating.
3. Keep asking questions and push to discover the next piece of the puzzle
Extracting insight sometimes involves thinking and acting like a detective. There can be some real mysteries in software, and sources of inaccurate information that might throw you off-course. Other people on the team might provide “witness statements” as to the software’s behaviour, but sometimes things don’t add up. Get creative and think of other ways to verify information, test your theories, and find more clues.
4. Take a step back
Being able to focus and defocus is an important skill for a tester. Remember to take a step back every so often and look at things from a different perspective. Some clues might not lead to anything, and others might only make sense when paired with others. Shuffle things around and look for less obvious connections, patterns, and groupings.
5. Use models and heuristics for inspiration
Models and heuristics are great for generating test ideas. You can also use them to form connections between puzzle pieces. If you’re struggling to see what the bigger picture might be, use these tools to think about what the pieces have in common, and what’s linking them all together.
6. Focus on impact and consequences
Remember that providing insight means telling a story and making it matter. Always relate your findings to the impact they’ll have on the business, customers, users, and the team. Ask yourself, “so what?” Why should stakeholders care about what you’ve found? What will happen if they do or don’t act on it? Try using the inverted pyramid method advocated by Michael Bolton.
7. Tailor to your audience
Different stakeholders have different concerns and priorities. Take this into account when delivering insight and telling the story. Those on the business side might take more interest in costs, delivery time, and sellable features. Product and operations teams might be more focussed on technical debt, avoiding urgent or complex issues, and any extra work or overtime that might be asked of them. Understand what your audience cares about and make the story relevant to them.
8. Be prepared to share your findings
When delivering insight, telling the story might be part one of two. Depending on your audience, some stakeholders might be happy to base decisions on the story alone, whereas others might use it as an introduction to further information. How did you put the story together? Can you explain some of the puzzles pieces in more detail? Providing insight isn’t about making unfounded claims, so be prepared to evidence how the story came together.
9. Offer balanced options for action
A good indicator that you’ve effectively provided insight is a stakeholder asking you for recommendations on how to move forward. Be aware of your biases and offer balanced options that don’t just serve your own needs. Sometimes you may be asked for one specific recommendation. In this case, if you avoid advocating any one option, it can be frustrating for the person seeking advice. Decide which option you would choose if it were up to you, and share your reasons to open up discussion and invite objections.
10. Remember your purpose
Testers ask questions, help minimise surprises, and enable stakeholders to make informed decisions. Going further by providing insight involves extra work and effort, so it might feel disappointing if no action is taken following your insight. However, it might be that taking no action is the best option in some cases. What’s important is that stakeholders are now fully aware of the issue and have made the conscious, informed decision not to take further action at this point. Should negative consequences arise from this in future, they will be anticipated consequences, instead of surprises.
Do you have any other tips on how to provide insight? Please share your thoughts in the comments.
Thank you Cassandra for a very interesting read. Having been in testing for a long time starting in a very adversarial environment where testers and developers were both measured on bugs logged! I found that describing the behaviour rather ‘the problem’ helped conversions. Nowadays I tell everyone that I don’t find bugs, I only describe behaviour. Alongside actionable insights. ‘I’m seeing this behaviour when I do that. I actually expected this. Could we try X to get closer to expectations or am I missing some information?’
So my tip is, don’t find bugs, describe the behaviour and collaborate to reach shared understanding and agreement about what to do next.
Hi Ady,
Thanks for your comment.
That’s a great tip! It works well with the idea of, “1. Is there a problem here? 2. Are we okay with it?”
It also gets around the, “it’s not a bug, it’s a feature,” argument, as you’re framing it as behaviour and opening up a conversation from there 🙂 I also like how you frame it in terms of expectations, as I think that’s really important when thinking about UX.
Thanks,
Cassandra