Interview With Callum Akehurst-Ryan
Callum Cakehurst-Ryan (he/him) is a Senior Test Engineer with 14 years of experience across multiple domains from finance to public safety. His technical skills and keen interest in exploratory testing techniques are backed up with a passion for team engagement and the advocation for the integration of testers into agile teams.
Using his background in psychology, Callum engages teams with quality narratives surrounding human factors; providing insights on how individual and diverse users will engage and experience their products in different ways.
In his spare time he’s also a kick-ass Dungeon Master.
I read your blog post SPEAKING UP IN MEETINGS – AN AWESOME POWER and it got me thinking. How do you encourage the quieter ones to speak up at meetings when you may have a few people dominate discussions?
I believe that wanting to speak up in meetings is all about feeling safe to share opinions and to feel like you’ll be heard. I use some improv skills to really engage with other people in meetings, actively listening to show that I’m paying attention and engaging and then using “yes and” to build on ideas.
Building on ideas is a great technique because it helps people feel like they’re not being shut down and therefore feel safe about speaking up.
To support a safe space environment I talk to people like they’re real people. I strip out jargon to talk plainly, show my vulnerabilities and share aspects of my life with my team. I’ve also used a mascot to make sure that my messaging isn’t just “this is bad” and negative, as that could make people not feel safe to talk to me and contribute.
When you have some dominant characters in meetings who may take over the discussions there’s a number of things we can do. I either look to facilitate the discussion by asking what everybody thinks and elicit further conversation; or as my position of a tester I’m happy to ask questions to ensure we all have understanding (as I’ve found that some people are quiet because they don’t want to appear stupid).
You’ve given a few talks on how diversity can help teams or testing. Have you struggled to get people to properly realise that? I sometimes feel (based on my experience) that people think that diversity is a nice idea. But not that it has tangible benefits.
As a gay man in engineering diversity is really important to me, not only within office culture but also when we think about how we build our products. I’ve learned a great deal from my colleagues/managers who are women who’ve said; you get more response from inspiring rather than punishing.
Because of that I try to do things that inspire, like sharing LGBTQ+ history to help build empathy in my teams for different types of people.
I’ve certainly had pushback from the “this is a nice idea but there’s no benefits” mentality, usually around making changes for accessibility to products. In those situations I’ve tried to educate people by running workshops (with the awesome @elizafx) on what accessibility needs our users may have and show how we can make a difference.
Recently I’ve won over some product people by doing a low hanging fruit audit of a UI using Axe to create narratives about how we can make our product more usable / accessible to make it more sellable to customers.
You’ve worked in a wide variety of industry sectors Fintech, Finance, Banking, Broadcast, Retail and Public Safety. Have you been able to carry any knowledge and apply if so what?
Mostly it’s been being able to build and use different testing skills and knowing what’ll work universally. Working across different domains means that rather than having to rely on domain knowledge for testing, I focus on my testing skills. I’m comfortable coming into a new domain as I know that critical analysis, exploratory testing and being able to pick up architecture will mean I can get going quickly.
My early career was in banking, so I’ve been able to bring a mentality of traceability and reporting to my work from that. Then more recently, I’ve brought a collaborative getting hands-on style of testing from the start ups that I’ve worked in from different industries.
You’ve written about how playing DND (Dungeons & Dragons) has helped you with your work. What’s the biggest benefit you’ve noticed?
I’m actually writing a talk about this for TestBashX in March! It’s a topic that I’m really excited about because it brings together both of my passions for roleplaying and testing.
I think that one of the biggest benefits that I’ve gained from role playing games is that ability to say “yes… and” to things that other people say.
It’s an improv skill where you listen to someone and then build on what they’re saying (rather than just doing your own thing).
In a team that’s really valuable because it helps keep ideas moving, creates a safe space to try things and also shows that as a tester you’re not a roadblock.
“Yes and we can add error handling for if the network falls over” just sounds better than “that won’t work because the network will fail”. Oh and dragon slaying, that’s a really good skill to have too!
I see you are very passionate about exploratory testing. But what about test cases? When do you decide they may be a better fit for the situation? And when do you think ET is most suitable?
Test cases and scripts are for when we want to confirm what we already know to be true, so they’re great for regression or in an environment where things are highly designed by specification. Generally on my projects, these get automated so test scripts are an awesome candidate for automation.
Then we use planned and structured exploration to investigate what we don’t know about. This is really powerful in times of uncertainty where things are not strongly specified, or when we’ve used user stories to specify the what and not the how. We can explore to find out how something can be done and then playback quality narratives about how that works.
Although I think exploratory testing is something we can always use, we might not want to always use it. It’s something that some organisations, teams and testers are not familiar or comfortable with and you have to be able to advocate for its use in an organisation.
I’ve written about sharing exploratory testing with developers and there are resources out there if you’d like to do the same. However, if you or your team / organisation don’t want to push for this style of testing then it may not be a good fit for you.
I’d recommend trying it though: it’s a good skill to have, helps build rapport with your team and is fun to do.