Michael Larsen (INTRO):
Hello, and welcome to The Testing Show.
Episode 150.
Test Coaching.
This episode was recorded on Wednesday, December 11, 2024.
In this episode, Mike Talks joins Matthew Heusser and Michael Larsen about Test Coaching and ways to assess team strengths, weaknesses, and ways of working. They focus on how to help build rapport and develop a culture of feedback, open communication, and getting away from the “one-size-fits-all” approach to help testers and test teams best succeed.
And with that, on with the show.
Matthew Heusser (00:00):
Welcome back to The Testing Show. For us, we’re getting close to the Christmas season. You may be hearing this in early January, but today we’ve got Mike Talks. Now Mike is from New Zealand, right? Not Australia. New Zealand.
Mike Talks (00:15):
New Zealand, originally from the UK.
Matthew Heusser (00:18):
OK, and he’s got 20, 30 years in software development, IT, testing. He actually started out with a bachelor’s and master’s degree in physics and then ended up in IT. I met Mike at Agile Testing Days. A couple times, I think…
Mike Talks (00:35):
That’s actually a lie.
Matthew Heusser (00:37):
No? when did I meet you first?
Mike Talks (00:38):
I do believe you came over to New Zealand to do a testing conference in 2014.
Matthew Heusser (00:43):
Oh Yeah! Of course.
Mike Talks (00:43):
And that’s how we collided the first time around.
Matthew Heusser (00:47):
Yeah! That was such a whirlwind, because we had to do Auckland one day and Wellington the next, it was such a whirlwind. I’m so sorry. Wow.
Mike Talks (00:54):
And you brought these little Scrabble games. It would do tiles and you could connect them together to get points to go, “Hey everyone, test this!” And it’s like, “yeah, there’s lots of words you haven’t thought of.”
Matthew Heusser (01:06):
I think that was the first long-form tutorial I ever taught or one of the first,
Mike Talks (01:11):
Yeah,
Matthew Heusser (01:11):
So yeah, that was a while ago.
Mike Talks (01:14):
You drafted me in secretly through a message saying, “Hey, I’m going to be doing this workshop. Please come to my workshop. I need an extra pair of hands for this.”
Matthew Heusser (01:21):
Yeah, you were kind of in the community. Agile Testing Days is in Germany. It’s the second largest Agile conference, and what I like to say is if you get there from another continent, you either really like testing, or you’re really good at it, or you have a lot of money, but at least two out of three, you were working on chatbots at the time.
Mike Talks (01:42):
Yeah, that’s right. My little team came third in the Software Testing World Cup the year before I was dreadfully ill on the actual day and trying to organize things from a hotel room. I was sick as a dog
Matthew Heusser (02:01):
And you just made it on this show. We’re so glad to have you here, but we’re going to talk today about… towards the latter half/tail end of your career. You’ve been doing a lot of coaching of testers.
Mike Talks (02:11):
Oh yeah.
Matthew Heusser (02:12):
And your current role is test product owner, is that correct?
Mike Talks (02:16):
Yeah, it’s becoming more formal QA manager, but the technical product owner for testing was my original job title and it’s actually closest to what I do on a day-to-day level. It’s close to what some people might call an engineering manager for testers, but a lot of it is not just helping with process but helping to coach the individuals. So lots of coaching a bit of product. That’s a really good role for me, like this big smorgasbord of stuff, some release management as well. It’s just nothing’s off the cards, which is great until I try and explain the role to somebody and then I sound a little bit crazed because I do a little bit of everything, but I’m one of those people that really gets off on having a mix of things to do rather than just creating a groove in what I do.
(03:01):
And I only do this one thing and very rarely anything much after that course and probably a good amount of that is just driven by the fact that despite a lot of what is said about testing, testing kind of touches so many area in software development. Probably one of the biggest things I’m coaching at the minute is the importance of testers and collaboration to find those problems early. A big piece from Lisa Crispin and Janet Gregory in their book “Agile Testing” about the importance of finding problems before you even build the code. They call it shift-left these days. It’s the ultimate shift left. Often people think about shift left being a tool, but finding a problem with code you’re going to build before you actually build it is really the ultimate way to save money.
Michael Larsen (03:45):
So I want to jump in here if I can. It’s interesting that you just talked about being a product owner over testing. We just recently did a podcast with another presenter that was on our show who was talking about her role as being a product owner in test, and so it sounds like there’s a lot of familiarity here and it does seem that a lot of the idea behind that is that there’s a lot of coaching and a lot of aspects to that. So I want to hone in on the coaching aspect of course. How would you go about that? What would a typical, if there is such a thing as a typical test coaching session, look like for you?
Mike Talks (04:24):
I think one of the first things to do is just usually I’m hired by company or previously I will be brought in to a customer. You’re always brought in any kind of role because someone has acknowledged there’s some kind of problem. We’re not getting the best out of our team or our process for some reason. I think a lot of us can talk about things like what’s our ideal test team and stuff. Well, you don’t often get that benefit of building a team from the ground up. Often you’re looking at a team and you need to really understand what are we trying to deliver as a product here? What are our processes and what kind of people have we got and what did they do well? What did they do less than well? I mean I can’t help but think of this a bit in terms of we get very hung up in IT management and thinking ourselves as generals, but there is a particular game that my son really enjoys.
(05:14):
The Rome Total War game. You’ve given an army and you need to try and get victory conditions with this army. And he would go, oh, I’ll always play as the Romans. I know how the Romans play really well, but there’s other armies that don’t do that whole shield wall thing that the Romans do and they operate really differently and you need to understand how that army works really well to go, okay, I can’t use them like a Roman army, but I can use them differently, particularly in the area that I’m in at the minute, for instance. a lot of the people that took on testing roles prior to me joining these companies had kind of risen through the ranks. They understood the systems, the business, the culture, so they were really strong business testers, but not so great at really looking at things from a technical perspective. We had a couple of really strong technical testers and trying to work out, okay, this is the makeup of the team.
(06:03):
How do I strengthen our technical ability? How do we help to train them? It’s really important in every conversation is to say, yeah, but let’s not forget the business part is really important. It really helps to have people who’ve been in the industry for 10, 20 years and really know not just our customers want, but really how our products should operate. So a lot of it is, I think I was on an assignment about 10 years ago and someone said to me in the first two days, I’m sure you’ve got lots of ideas about how to improve things. And I went, well, yes, yeah, yes I do, and I think I got this from Jerry Weinberg, but first two weeks you keep your eyes open and your mouth kind of shut and you just kind of watch, observe. You have conversations with people, you try and have those conversations with everyone. You’re building up rapport is really key so that people feel comfortable about opening up to you. You’re not to do an assessment on people. It’s really to break down walls and try and find out what works, what doesn’t. It’s as important to communicate what really works as what doesn’t and what doesn’t work becomes your problem area of, “Right. How do we work through that?” Coffee chats, being nonthreatening, trying to not approach everyone with a clipboard (that’s always kind of worrying, isn’t it?) is pretty key.
Michael Larsen (07:26):
To follow on with this because I definitely know the feeling having just gotten into a new company and looking at things from a perspective of that new person, but that new person who has a long pedigree of doing testing and also realizing that I’m doing testing, part of the reason they brought me on was that I have abilities that they either did not have or were not focusing on at that given point in time and hey, grateful for it. Absolutely. But it’s been very interesting because I’ve had this give and take with a small team that I’m working with right now, some testers who have been involved for a very long time in the industry and some who are more DevOpsy type stuff. And we are all sort of working together on these things and it’s interesting to see who ends up being the mentor at a given moment or a coach and who ends up getting coached. And oftentimes the hat shifts, so it’s not like I am coach, I teach you what to do. Very often, in the moment, the roles switch. And so being able to handle that and being able to work in that kind of a way to where it’s not a one way conversation. I have a feeling that that’s probably something you’re familiar with. So how do you find when it’s time to switch gears or is that a common situation that you deal with?
Mike Talks (08:52):
I think it’s a common situation to deal with and I think it’s actually really great that you’ve kind of brought this up. I think it was a conversation I had with James Bach about 10 years ago when we talked about this. You go into a business… now, something about the technology might be unusual to you, something about the industry might be brand new to you. What he basically said to me was… this was about himself. “When I go into a company, I know that I am the testing expert. Testing is my thing. I understand testing” and in a similar way when I go into a company, I know that I know how to deliver IT and I know all about how to deliver really high class testing with something like the Software Testing World Cup, which was fantastic even when you only learn the product half an hour before you actually get started.
(09:36):
But I feel from a humility point of view, and again this is about building that rapport, it’s best to come in and say, “Look, I’m going to help you to test, but I don’t understand your tech stack. I don’t understand everything about your business.” I’m a big believer in leading in the same way that I want others to lead. Part of that is things like if I work on initiative or a particular approach to something, I don’t just go, “Oh, I’ve come up with this really great approach. This is the way we’re doing things.” I try and build a feedback culture. Building a feedback culture involves things like building up trust or rapport like we say, and I think it’s really important if I’ve got a senior tester working for me who I’m expecting to get feedback from me, as a lead, I also need to on anything I work, seek feedback from the team around me.
(10:25):
I do that because it helps to break down barriers. It kind of sets the thing of “you’re never too big that you shouldn’t be seeking feedback.” It also allows me to take an idea… and I think there’s a lot of power in this; we’ll look at things and go, “How can we get things faster?” What I noticed I’ve done a lot since I’ve become a manager is I often become that person in the meeting that comes up with a really terrible idea. “We need to get it faster. How about if we do… and I know it’s going out there on a limb and a prayer, but what it often signals is we’re going to kind of flip the table on this. We’re going to try something different. And people will say, “We can’t do it like that. Well, why can’t we do it?” And they’ll tell me a reason and I’ll learn something.
(11:06):
If you engage properly and it’s a really tricky kind of facilitation skill, people will go, “Yeah, we couldn’t do it like that, but we could try this” and that is that breaking people out their comfort zone and saying, we could try. Then you start asking the follow on questions of what’s the risk about that? What would we need for that? And then you start building up a shopping list and then it becomes all of a sudden something to kind of break the deadlock in how we currently deliver software and really try and become a bit more leaner in our approach, be able to adapt a little bit more, and that’s really key. We tend to stick to an island of, “This is what we’ve always done” because it feels safe, but changing anything is going out on a limb and going out on a limb is also putting your head in the cross hairs. So encouraging that kind of engagement is, to me, a really big part of coaching, but you can’t do that without having built that trust, showing that you have value in others, showing that you value feedback and honest, genuine feedback as well.
Matthew Heusser (12:11):
So one thing that I really pick up from Mike, having met him in person a couple of times, you say honest and genuinely, you really just come through as the nice guy that you actually listen to people, you try to build consensus and that’s your style. I think that really is to your benefit as a coach. That can be challenging in environments of low trust. If someone’s got a more bullying personality, they’ll walk all over the nice guy. I’m sure you have techniques to deal with that, and I do want to talk about how to deal with difficult. You’re trying to give feedback to someone who you’ve gotten a lot of negative comments about lately and you’re trying to help sort out what’s really going on. If you’ll permit me before we go there, let’s talk about Scrabble flash. Yes. And Michael’s played Scrabble Flash too, right? I’m sure he has.
Michael Larsen (12:58):
Yes, I have.
Matthew Heusser (12:59):
It’s been a while.
(13:00):
Probably before Covid, so if you’re going to get value out of this conversation, say, “Hey, Matt, I gave you 35 minutes of my time” and I go out, buy three copies of Scrabble flash online, bring ’em into your team. If you just play it, split ’em into three teams, play it and compare the results that you found a risk to product”, you’ll find different kinds of problems. Why did you find those? Why did you find those? What we’ve found, we were doing 15 minutes of test strategy followed by 30 minutes of using the product. We get teams that go in completely different directions. We need to take it to a birthday party and we need to do a beta test because these five little cubes that sense each other’s location and organize the random letters into words, we need to see what happens when you spill soda on it or how long the battery lasts, which you don’t get if you’re just playing with it for half an hour. So that’s the value. Any other thoughts you have around that? I just have to mention it. This is go buy it. You’ll love it.
Mike Talks (14:01):
Well, yeah. I think the person I’d most want to get involved is my wife. I’m slightly dyslexic, so between the two of us, we have the potential to be one of the smartest people in the room together. I could do all the mathematics standing on my head type stuff. Well, we’ve been together close to 29 years now, and I think we’ve only played Scrabble about two or three times, and that’s because… she’s not only very good at it, she’s kind of a bit rude about it as well, so there’s a certain word task that she’s done, she’s doing at the minute, and I think for April Fools, yeah, there was one word that you had to do backwards, and she was furious. She was so furious. You got a ring of letters and you have to join them together to make the word combinations, and occasionally she’ll find something and she goes, “No, that’s the American spelling. I hate this game.” Obviously, we use the English spelling over here. I’m sure that was a factor actually in Scrabble words.
Matthew Heusser (14:57):
And that brings out the importance of subject matter expertise. You have either a manager role or a coaching role. Your coaching is a part of what you do. You’re a senior, your staff, have gotten criticism for their interactions. You’re hearing from outside the team or maybe in a cross-functional team and from other disciplines about issues with their behavior, but they’re really good technically or they’re great, everybody loves them, but you’ve noticed this has missed a lot of bugs or they could struggle with the technology and things take longer than you would think that they should. So what you’re trying to do is figure out what’s going on to help the whole team improve. I don’t know if you would call it a counseling session, a coaching session, a one-on-one. Have you ever had that? What do you say?
Mike Talks (15:48):
I think what you’ve described, I’ve come across as examples in my coaching. I will say though, first of all, I’ve never met somebody with all of those things, thankfully. But you tend to…
Matthew Heusser (16:00):
I Would hope not.
Mike Talks (16:02):
I think one of the most important things is the minute you hear about any kind of perception issue with anyone, you’ve got to follow up on it. One of the most important things is, apart from the fact that I make sure I have monthly catch-ups and informal catch-ups beyond that with everyone in my team, so just to check how they’re going and stuff, one of the biggest things is you can’t let feedback build to an annual review and then go, “Hey, it’s December now, but remember in March you did this thing? Well, we didn’t like it.” Feedback always needs to be given really, really quickly, but you also need to do a bit of a deep dive. There’s people I’ve worked with who have been perceived as a problem, and I’ve worked out, I’ve got that feedback, come back to it, looked at what they’ve been doing and gone, huh…
(16:48):
It’s not so much there’s a problem with this person but there’s a perception with that individual… perception. They said, “Look, we’ve just got to work on helping you to project more of what you’re doing. Somebody’s asking you to do something and you are working on something different. You’re working on something different because you see it as really important and we’ve had the conversation. It’s actually really important, but you’re not handling, well, letting people know why you’re making some of the decisions that you’re making.” So that might be a whole area of coaching that we don’t work on for about three months. How do we handle that communications for the person that seems to be working through really slowly and No, no, this is a huge thing, particularly when we have test management tools. It becomes very easy for people to track person A against person B, and person A seems to be working at half the speed of person B, therefore person A must be wrong, and it couldn’t be potentially that person B is perhaps going through things too fast, isn’t actually finding problems, so haven’t cut the conversations with any kind of stakeholder that’s dealing with a tester and saying, look, you need to appreciate testing isn’t just a race to the finish.
(17:51):
It’s also that we need to be finding some issues.” But from a conversation like that, it could be things like, I’ve got quite a lot of product unfamiliarity with this area of the product, so it becomes immediately, “Okay, how do we work on this? How do we build up this product knowledge?” Yeah, and I think with different testers, product knowledge is a whole thing. We have to be really familiar, particularly the way that we structure our test these days. Usually literally you’re given a shopping list of try these four things, but the back process of how you might do this, and some of them might include some sending particular flags and that person through a back office, which is not a really easy thing to know. It takes a bit of learning. From my perspective, it’s making sure that we’ve got resources to help train people as required with individual testers.
(18:37):
I sometimes see two extremes of behavior, which are both worrying, one of which is they try and solve everything themselves, and instead of a task taking 15 minutes, it takes an hour or more because they’re just going deeper and deeper and deeper and they can’t solve that problem. But that individual, a bit of coaching of, “It’s okay to reach out.” We’re trying to help them to say, “When you don’t know, you need to reach out to other people and you need to make it really clear that you’ve tried to do this. You spent some time doing this, but you’re currently just kind of burning time. You really need that help. I’ve tried doing this, this, this, and this.” Now, the other end of the spectrum of that tends to be people who every time they hit a roadblock, “I need help doing this and I need help with doing this,” and people will say, “Look at the channel,” and you’ll just see them asking one question after another.
(19:24):
How do we get them to be more self-sufficient? With that person, I’ll go “Look. You’re asking a lot of questions. Some of the questions have been noted that you asking how to do something. Are you making notes when somebody tells you, so the action plan will be different on the person?” I do try and encourage as much as possible to get rid of that idea that a QA can feel like a nuisance as always show you’re working out, going, “I’ve tried to do this, gone through the help. I’ve gone through the admin thing. This is the person I tried to do and it just couldn’t get it to work it. What am I missing?” To show that it’s not just every time that you have an issue, you just kind of put your hands up and say, “This doesn’t work.”
Matthew Heusser (20:02):
What I hear you saying, and I think this is really important, it’s not a people issue. It’s not a… I’m going to pick on Michael for a second. We can re-edit it if he hates it, but it’s not, “Michael keeps screwing up!” It may be a skill issue, it may be a communication skill issue. It may be a training issue. It may be even an aptitude issue in some cases, but reframe it away from, “You’re the problem” to “What is the problem and how do we fix it?” The only other thing I would add, then I’ll go it to Michael and let you wrap up. In my experience, one thing we can do if that actually happen and be like, “Okay, can I facilitate a conversation between you and Michael? Because I don’t even want to be in the middle of this! If you have expectations that he’s not meeting, you two can talk and I have some skills to help make that conversation be productive.” Sometimes when the person actually has dark motivations, they’ll run away from that, so “Well, okay, if you aren’t willing to have a conversation about it, I guess it’s not that big a problem.”
Mike Talks (21:03):
Sometimes it can be, but most times it is. Everyone needs to grow.
Matthew Heusser (21:08):
Well, that should be our operating assumption. Our beginning operating assumptions is not the person, and sometimes it’s the problem is the way the person wants to be is not compatible with this environment. Something can get there eventually.
Mike Talks (21:21):
Yeah. Something I use for our annual goal setting and their annual reviews is ideally you enter the industry at a certain age and potentially about 40 years later you retire and the person who retires in 40 years should not look like the person who entered. You need different skills. Different skills, the technology changes, the list goes on. So we’re forever adapting not just to the technology we’re using, how we’re delivering it, how we actually build software. These have changed dramatically over the last 15 years. Consequently, we need to just keep adding skills, an Agile tester is very different to a Waterfall tester. You need to be a lot more personable. As a waterfall tester, you just needed to read the damn requirements. Now it’s really important that you kind of take problem ownership and you talk to people and stuff. There is a changing skillset and it’s important to reflect that, respond to that, and understand that there’s ways that we all need to have constant improvements.
(22:22):
Also, it’s important to have these conversations and have them fairly, having done your research, worked out where the actual issue is, explore that issue with that person. Not everything has to be disciplined, but don’t get me wrong, I will follow a disciplinary action if I need to. Most times it’s a case of, “No, we just need to work on a couple of things.” Often the person that you bring it up is actually relieved about this because this has been actually something worrying them. “Yeah, I’ve been struggling for this for a while, didn’t really know to get help. How can we handle this better?” That should be my going away, so don’t be afraid of these conversations.
Michael Larsen (22:58):
And with that, I’d like to also add a little bit here. I agree with you in this, and I think sometimes that’s probably where most of us end up making the biggest mistake is we don’t seek help or we’re pretty sure we’ll just figure it out and sometimes we just don’t. Or in my case, I’ve been, I will call it blessed because the company that I’m working with right now, I do appreciate the fact that everybody from senior staff to even us new people here, they all say the same thing. We get it. This is a ridiculously complicated product, so we do not expect you to know everything. I’ve been here for almost two and a half months, and I’m still asking what I feel like are remedial questions, and at times I just go, “Oh gosh, they must think I’m the biggest idiot.”: Thankfully, the answer is usually along the lines of, “We’ve had people who’ve been here for four and five years and they’re still discovering things about this product.
(23:58):
That’s the nature of it. Don’t feel ashamed or that you’re not the one who has all the answers.” Of course, you don’t have all the answers, but what you need to do is accept the fact that you’re not always going to be the know-it-all. You’re not always going to know what you have to do, but at the end of the day, if you share that and you admit it, but you’re showing that you are either by documenting things or by recording videos about them or sharing them with other people or teaching other people, you put that forward and everybody else knows that because you’re doing that, they can do it too, and it evens the playing field tremendously. And Mike, how can people find you if they want to talk to you?
Mike Talks (24:43):
Oh, that’s a whole question at the minute. I think we’re all abandoning Twitter at the minute for Blue Sky. I’m there as… I think it’s Mike Torkelson. I have an author name and have an IT name, and I’ve tried to fuse the two together to come up with something at the minute because running two Twitter accounts got exhausting after a while, so I’m on there. But if you look under, if you Google for “Test Sheep New Zealand”, you’ll find my webpage at loads of fabulous resources to have a bit of a play around with.
Michael Larsen (25:14):
Awesome. Fantastic. Well, with that, I’m going to say thank you so much, Mike, for joining us. Thank you, Matt, for hosting us as always, and for everybody who’ve been listening, thank you so much for listening to another episode of The Testing Show, and we will be back soon. Take care, everybody.
Michael Larsen (OUTRO):
That concludes this episode of the Testing Show.
We also want to encourage you, our listeners to give us a rating and a review on Apple Podcasts, Youtube Music, and Spotify.
Those ratings and reviews help raise the visibility of the show and let more people find us.
Matt and Michael have written a book that has distilled many years of this podcast along with our decades of experiences and you can get a copy of it for yourself. “Software Testing Strategies: a Testing Guide for the 2020s” is available from Packt Publishing and is available from Packt directly, from Amazon, Barnes and Noble, and many other online booksellers.
Also, we want to invite you to come join us on The Testing Show Slack channel as a way to communicate about the show.
Talk to us about what you like and what you’d like to hear. And also to help us shape future shows, please email us at [email protected] and we will send you an invite to join the group.
The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Thanks for listening.
