Panelists
Have you ever noticed that there seems to be a certain level of dysfunction that can take hold in various companies? If that may feel like too strong a word, consider it traits that numerous software testing individuals often exhibit, whether they intend to or not.
Kristin Jackvony joins Matthew Heusser and Michael Larsen to discuss six personas (and perhaps some additional variations) that could spell trouble for projects and programs. The tricky part? We might very well recognize these personas in our organization and possibly in ourselves.
References
- Think Like a Tester
- “The Complete Software Tester: Concepts, Skills, and Strategies for High-Quality Testing”
- Six Testing Personas to Avoid
- Finding Joe
- Postman Essential Training (LinkedIn Learning)
- STPcon @ InflectraCon 2022
Transcript
Michael Larsen (INTRO):
Hello, and welcome to The Testing Show.
Episode 111
Six Personas in Software Testing to Avoid
This show was recorded Friday, February 11th, 2022.
We welcome Kristin Jackvony to the show to discuss six software testing personas (and perhaps some additional variations) that can spell trouble for organizations and what we can do to avoid those personas going forward.
And with that, on with the show!
Matthew Heusser (00:00):
Hey, thanks, Michael. As you mentioned this month, we have Kristin Jackvony, who is a principal engineer for quality at Paylocity. Before that, she was a staff engineer in test. She’s been a quality assurance manager, contributor… not a consultant, not, in particular, selling anything, but she did just finish her book, “The Complete Software Tester: Concepts, Skills, and Strategies for High-Quality Testing”. And she wanted to talk about it. And we’d love to hear this new idea, Six Personas in Software Testing to Avoid. What’s the conceit behind that? What do you get at when you say “to avoid?”
Kristin Jackvony (00:43):
Well, I was thinking about how, when we develop software, we often come up with user personas. We think about, for example, if somebody was making a home improvement application, they might want to be thinking of one of their users as “New Homeowner Harry” or something like that. And as I was thinking about that, I was thinking, well, you know, as testers, we can sometimes fall into tester personas and there are a bunch of those that we should really avoid. Probably people listening will think to themselves, oh, I know somebody that does that. Or they might even see themselves in some of the personas.
Matthew Heusser (01:24):
And this could be, “I don’t wanna turn into that person, but also as a manager, I don’t wanna hire that person. I don’t wanna let my people become that person accidentally through rewarding the wrong behaviors.” All of that applies?
Kristin Jackvony (01:38):
Absolutely.
Matthew Heusser (01:40):
So let’s talk about the first one, Test Script Ted. What does Test Script Ted do?
Kristin Jackvony (01:45):
Test Script Ted is somebody that really just wants to follow directions. They want to be given test plans to run. They want to go through the test plans, check ’em off as either pass or fail. And they don’t really want to have to do any thinking. The trouble with Test Script Ted is he’s not really learning things about the application. That means if Ted sees something that looks funny when he’s testing but it’s not part of the test script, he’s just going to ignore it. He’s not going to take a look at what it’s actually supposed to do. That’s where big bugs can get missed.
Michael Larsen (02:26):
I wanna jump in here real fast, just from the perspective of, I love the idea of these personas because many of us inhabit them, whether we mean to or not. And Test Script Ted is somebody sort of near and dear to my heart because I definitely appreciate how this can come into fruition, especially when organizations get very adamant about the need for test scripts. So I look at Test Script Ted as two people, and maybe you can help me if I’m looking at this the wrong way. On one side there’s Test Script Ted number 1, who is, I need a blueprint to follow, and that blueprint must be precise. On its surface, not a terrible thing because depending on your organization, Ted might be interchangeable in the sense that Ted might be working on one project, but in two weeks, Ted might be working on another and they need to hit the ground running, having test scripts and needing to have those in place is in and of itself not a terrible thing. I’m with you though, that if they’re over-relying on the scripts and they’re not really learning, or questioning or opening up to trying different things, that would be a disadvantage. Here’s where I think that there’s a second problem. And maybe we can elaborate a bit and that’s Test Script-ER Ted because they’ve been told (and I’ve been in this position), “We need to have everything in rally or JIRA or some other platform that defines all of what your tests are. And the more definition and detail you give, the better everyone will be.” And I find myself needlessly having to script out all of this stuff, to give people all of the details that was necessary. And so many times I have had to do this because of some arbitrary need, it’s now in the repository and it never gets used. Nobody touches it. Heck I don’t even touch it because I spent so much time writing it, I know what to do, and I can riff in variation on it. And I do better testing just because, all right, the process was maybe a little helpful, cuz it got me to clarify what I had to do, but do I go back and reference those notes? No, I often don’t and then I realize almost nobody else does either. So it’s a wasted effort. Anyway. Just wanted to put that as maybe that is a part of number one or there’s a nuance there at someplace else. Maybe that leads into Automation Annie… by the way, that’s the next one, gang.
Kristin Jackvony (05:22):
Yes. I think some of what you’re mentioning actually goes into Process Patty who is persona number three. So before we get to her, I will talk about Automation Annie. Automation Annie is somebody who really loves writing test automation. And so when she sees that there’s a new feature coming down the pike, she’s all excited to just start writing the automation for it. But the problem with Automation Annie is that she is not really taking time to get to know the application. So while she might be writing automated tests, she’s not necessarily automating the right things. She’s not necessarily writing tests that are providing value and she might be missing very important features of the application because she hasn’t taken the time to really learn how it works.
Matthew Heusser (06:18):
And you might say that in some ways there’s a root error here, which I think is… coming up with test design is hard. Although we’ll never talk about how to come up with test ideas. So if we could just get it all written down, we don’t have to think about it. And whether that is written down on paper or having a tool where you press a button and says everything is fine. “We don’t like to think, just tell us what to do. We’ll write these automation scripts and then we’ll press a button and we’ll get a green bar.” That really surprises me because I got in the testing because it was the thinking about it that was the fun part. I just don’t understand what these people are are on about. Maybe you have some insight?
Kristin Jackvony (07:00):
That’s a really good point. I think that sometimes people get into testing for those reasons because they’re excited about exploring the application and learning about it, but they wind up sort of slipping into a sense of security where, “Oh! Well now I’ve got my job. Now I know how to test. So I don’t need to grow.” You’ll see that as a theme sort of, as we talk about all these different personas, especially Job Security Jim, who’s persona number five.
Matthew Heusser (07:33):
Someone once said to me, “Yeah, you start out as kind of a human tester/manual tester. That’s kind of the 101. And then when you get to the 201, you start to get into performance.” I didn’t like the way that was framed. I have a master’s degree in computer science. You can find programmers all day long, but finding the people that can actually examine the software under limited time, with limited information, to explore, to provide quality related decision making information for management that are good at it is actually a much more rare skill.
Michael Larsen (08:09):
Interestingly, I went through one of these recently in just the way that they refer to us in our organization. Everybody that was a senior software tester or a quality assurance engineer because of a focus on emphasis, we all got title changes. And I thought it was really interesting when I got my title change that I was now a senior automation engineer. At first, I looked at that and I said, “That’s a strange fit for me.” Not that I have anything against automation and I do quite a bit of it, but I have often commented, and especially on this show, I probably spend 25% of my time doing any meaningful automation and 70% of my time poking around, prodding learning, understanding, conferring, and getting to really understand what the product is doing so that I can be effective with it. I spend a lot more hands-on time, even as an automation engineer. I guess it turned out that with a couple of exceptions, that was true for most of us, in the sense that our actual automation time was not as much as they had anticipated it was going to be. And so on an organizational level, it was determined that calling us all automation engineers, if we were not specifically writing the code and framework formally as our main job, didn’t make sense. And so most of us, I think almost all of us, were returned back to being senior quality assurance engineers, which frankly I feel better about because there’s more breadth to that. And that gives me more control and understanding of what’s going on. I didn’t sign up to be an automation engineer. So I’m actually happy that I’m not anymore. I hope that makes sense.
Matthew Heusser (10:13):
Yeah. Well it sounds like you’re flexing to do the needful. You’re flexing to do what the organization needs instead of following some rule documents somewhere about what your job is. I think that leads us into Process Patty who’s number three. Kristen, tell us about Process Patty.
Kristin Jackvony (10:30):
Okay. Process Patty is very interested in how the testing is going to get done. Process Patty is the kind of person that makes sure that there are test scripts for absolutely everything. When the testers that she works with are starting to test, she wants to make sure that they’re following all of the appropriate procedures. Regression testing needs to be completed before they can go on to doing exploratory testing, for example. Because of this, everybody gets bogged down. The focus is more on following the process than on actually interacting with the application. Thinking about it, following up on anything strange that may be observed, everyone’s just moving towards testing what’s in the script.
Matthew Heusser (11:22):
Yeah. So it’s kind of a myopic focus on doing what we thought six months ago we were supposed to do in order to call this thing done.
Kristin Jackvony (11:30):
Yeah.
Matthew Heusser (11:31):
So then testing is sort of a logical extension of development, it’s just the steps we have to do to call this thing done.
Kristin Jackvony (11:38):
Yep.
Matthew Heusser (11:39):
And I’m sure there’s lots of ways that can manifest that. There’s lots of ways of interpreting Process Patty that I think makes sense. I’ve certainly seen that and my experience with that is that once you do that, you are begging your company to outsource the work to the lowest possible cost check-boxing people. We were trying to get Gwen Iarussi on the show and the timing didn’t quite work out for her. But she said Checkbox Charlie, which is probably a similar kind of overlap with a couple of things here.
Kristin Jackvony (12:11):
Yes. I think Checkbox Charlie could probably be an amalgam of Test Script Ted and Process Patty.
Matthew Heusser (12:18):
And the next one is Rabbit Hole Ray?
Kristin Jackvony (12:19):
Yes. Rabbit Hole Ray is interesting. I’ve known a few Rabbit Hole Rays in my career. What happens with Rabbit Hole Ray is he’s doing some testing and he sees one very small thing that seems unusual to him. He starts pursuing that problem. He’s not able to reproduce it. He’s only seen it once, but he now is spending all of his time trying to find that bug that he’s seen to the exclusion of all else. So for example, you might be working towards a release and there needs to be a lot of regression testing done in order to say, “Yes, we think we’re ready for this release.” But rather than working through testing all of the different application areas, Rabbit Hole Ray is still trying to figure out why that button’s not showing up on Internet Explorer 10, even though IE has been deprecated and they are only 0.02% of the users. So he’s not doing the right things at the right time.
Michael Larsen (13:31):
I’ve had some experience with this. I’ve even been in this place. I’ve mentioned this because of the team that I’m on right now in the sense that even though I’ve been working with it for a couple of years now, I’m still very much the new guy in this team. Almost everybody else on this team has been involved with each other for a decade, maybe more. The challenge that I face as Rabbit Hole Ray is I think I understand what I’m doing. And I set up the parameters that I want. And as I start running through them and I start to see behaviors, okay, the behaviors make sense based off of what I’ve seen or what I’ve read, but they’re not quite lining up with what the story is intending, if that makes any sense, but I’ve gone through and I’ve done everything. And so the danger that I find myself in is sometimes is I get too fixated on it going, why am I not seeing what I’m supposed to be seeing? Let me do these, you line everything up, you focus on where everything is. Whereas had I stopped right at that point that I first had that inkling in my head that if I had just reached out to the developer and said, “Okay, I’ve set these things up, I’ve set these parameters, I’ve run the test. And here’s what I’m seeing,” I could have avoided hours or even days where I’m doing something that I think I’m doing right, only to discover where the developer says, “Oh, oh, I’m sorry. Yes, wait a minute. You did set that. And I know that that says that this is doing this thing, but what we’re really testing right now is this factor over here, it’s on a different page. It’s a different setting. And this is what you’re expecting to get. You’re looking at this from the perspective of, Hey, we’re generating an error and we’re supposed to get an email for it. And that setting is there. And that setting does say that. But we’re actually meaning to look at, does this actually get logged in a certain way? And that’s this feature over here.” Had I just had the wherewithal to think, let me ask them about this quickly, rather than trying to say, “I don’t wanna seem dumb. I’m gonna figure this out and I’m gonna make sure that I’ve got this covered,” I could avoid so much frustration if I just say, “Hey, maybe it’s just me. Maybe it’s just the fact that this team’s been together for a long time. And you all know this stuff like the back of your hand. Am I going about this right?” And it’s never been, “Oh, are you dumb? How could you have missed this?” It’s like, “Oh, you’re correct. That’s not worded well, I’m so sorry. Let me update this so that it’s a little clearer” and boom, we’re off to the races.
Matthew Heusser (16:18):
So you’re saying Insecure Ishmael. Like I do not know any persona names….
Michael Larsen (16:24):
(laughter) I think that is actually something that we look at or yeah, Timid Tim, if you will.
Matthew Heusser (16:29):
Timid Tim wouldn’t try it. Insecure Isaac would probably play into Job Security Jim. I mean, that’s one way insecurity can manifest is… well, you tell us how you see Job Security Jim, Kristin.
Kristin Jackvony (16:42):
Okay. Job Security Jim learned as much as he needed to learn in order to do his job when he first joined the company. But now there are some new tools coming about that some teams are starting to use, or there are some new techniques or perhaps a new language. He doesn’t wanna have anything to do with learning any of those new things. He wants to stick with his area of expertise. And often he is a real subject matter expert in his particular area because he’s been with the company for a long, long time, but he just wants to stay there and doesn’t want to learn anything new. The problem, of course, with Job Security Jim, his job is not going to be as secure because as time goes on, changes are going to be made and he might find himself shuffled out of his department or even shuffled out of a job.
Matthew Heusser (17:40):
What’s the fix for that? If I heard you correctly, that’s, “I’m the subject matter expertise. I’m the only one who knows the foo system.” And then we merge with another company. We offload all of our accounts from foo to bar and now nobody uses it at all. And that was my only expertise.
Kristin Jackvony (17:58):
Exactly. What Job Security Jim needs to do is he needs to be open to learning some new things. He needs to be open to not being an expert on something for a little while so that he can perhaps learn a new tool. Maybe let someone else show him what to do so that he can continue to expand his skills and be a learner.
Michael Larsen (18:23):
I’ve had some experience with people like this. And to be honest, I’ve actually maybe even been in this place myself a long time back. And I got some very good advice from a manager that I was working with at the time. “If we put this in place and I’m able to make this happen, I’m basically putting myself out of a job.” I said it jokingly, but not entirely as a joke because I was actually concerned about that at that point in time. And my manager at the time took me aside and said, “Michael, trust me on this. If you are good enough to make a process work in such a way that you are “out of a job”, you are valuable enough for us to take that effort and apply it to other things. Never worry about if I do X, I’m going to put myself out of a job. Almost never happens. If you have that capability, you will be valuable in other places. Be willing to share your knowledge. Because if you are a person who and improves the process for everybody, you become tremendously valuable to your team and the organization.” And when I’ve heeded that advice it’s been proven right. And when I’ve been reluctant to heed that advice, I’ve backed myself into corners. Do with that what you will.
Matthew Heusser (19:50):
Yeah, I think that people just don’t like the expert who says “you can’t do that. It’s impossible. No, I’ll do it. You don’t know how. It would take too long to explain it to you. I need a month.” People do not like that person. And they’re like, why does it take a month? “Oh, (mumble mumble) reasons.” And I have seen entire systems be rewritten. Like I saw a system rewritten with high volume test automation where they just took yesterday’s data, ran it through, got the results, exported it to a text file. A process that took two weeks suddenly took two hours. All of the people involved in that, they were gone. Pretty quick. The people involved in the original. So yeah, totally. That makes a ton of sense to me, which leads us to Conference Connie. Who’s Conference Connie?
Kristin Jackvony (20:45):
Conference Connie is somebody who loves to learn new things to the exclusion of all else. So conference Connie is somebody who loves to go to software testing conferences and learn about all of the new testing tools that are out there. New automation frameworks. And she loves to take all of that information and rewrite all of the automation that she has on her team. But what happens when she does that is nothing is ever settled. Nothing can ever be built upon because she’s always refactoring that code or Conference Connie can also be the person who likes to spend all of their time just going to conferences, coming back, maybe to the team and talking about them but doesn’t actually implement anything. So there’s sort of two variations of Conference Connie.
Michael Larsen (21:45):
I can also add a third one and for a lot of us, in addition to going to conferences to learn, I consider that the “Ooh, shiny!” We like shiny, shiny is good. Can be good. Shiny can also be terribly distracting. But the third part to this, when you become part of the community and you present at conferences, there can be a bit of underlying resentment to that person. I recently had this experience where I was telling people, “Oh, by the way, there’s this conference coming up and I’m gonna be speaking at it. So it might be sort of neat if the team maybe got a chance to go to this conference.” And I could tell by some of the responses, I don’t think they meant it rudely, but I think there were some people that were like, “Who is this guy? And who does he think he is telling us what we should or shouldn’t be doing?” And maybe I’m misinterpreting that. But I definitely felt in certain moments that my being a speaker sets up something in a little bit of a different space. Do you have experience with that or is that a totally different tangent?
Kristin Jackvony (22:58):
I think that I have seen Conference Connie’s who are presenters at conferences who kind of present on the same thing over and over and over again, and the message doesn’t really evolve. And this is something interesting that I’m focusing on because I have been starting to speak at conferences. I spoke at one this week, I’m speaking at one next week. I’d like to be able to present new and interesting ideas, things that I’ve learned over the past year, the next time I do that conference.
Michael Larsen (23:31):
I can certainly appreciate that. Thank you.
Matthew Heusser (23:33):
I’ll add a couple things here that might get me in a little trouble. I think that some people really do wanna see change in the world. They may be frustrated that they haven’t been effective in the workplace. And so they go off on the speaker circuit where they are rewarded and appreciated, and there can be a contrapositive effect where you go off into the world, then your team is like, “It sure would be nice if you were here. Instead of taking all that vacation, flying all over the place.” And this is what happened to a mild extent with me. People were actually using the ideas I was proposing and talking about and having success with out in the world and having success with it. And I was starting to get clients while I had a day job. And the company said, “This is what we’re gonna do, Matt, we’re gonna let you do your crazy stuff on this project. Don’t tell anyone about it.” Which was weird. What’s happening? It turned out, people were recognizing that my ideas were successful. However, they challenged the status quo. So I was going to be allowed to break the company rules because these new ways of thinking were working, but I wasn’t allowed to admit it because we weren’t allowed to break the rule. And that was when it was time to get a new job. And you know, we talk about Qualitest a little bit on the show here and there. They’re our sponsor. I’ve worked with them on a few projects and they’ve never done that to me. And that kind of ties into one I made up. Maybe you disagree. Maybe it’s not a good fit for your list. I’m sure we could do this all day long. And thats Job Hopper Johnny. I ran into one person at a conference once and he told the story of how he did all this tooling and automation with particular set of kinds of tools that I don’t think really work. And it was a really weird conversation. He had this confidence and it was an open space event, so everyone is a speaker and he was, “oh yeah, sure. This is the way to go.” It wasn’t a regular conference where they vet the speakers. Eventually I figured out that he just switched jobs every six months. So he had an impressive resume. He went around and told people how to do software. He didn’t stick around long enough to see if his ideas really work, he just got the proof of concept going. And then he took off. Is my experience unique with those?
Kristin Jackvony (25:50):
I have definitely seen that. I’ve seen Job Hopper Jim I’ve interviewed some Job Hopper Jims. I think he may be a variation of Automation Annie, because what he really wants to do is he really wants to stand up the projects. That’s the fun part for him. He doesn’t want to have to do is have to deal with the messy middle of the project where maybe some of his automation isn’t working as perfectly as he was hoping that it would.
Michael Larsen (26:19):
So Kristin, we’ve been talking a whole bunch about these testing personas and a bunch of other ones too. What are some things that we might be able to do? Something that we as testers could take away to say, “If you recognize some of this in yourself, here is something quick to consider so that you can avoid going even further into these negative personas?”
Kristin Jackvony (26:43):
Sure. The cool thing about these six personas is that they sort of come in pairs and the solution for those pairs is kind of similar. For Test Script Ted and Automation Annie, what both of them are missing is they need to take time to learn about the application. So for them, the fix would be start going to feature meetings. Start reading through the acceptance criteria more carefully. Make sure that you’re asking good questions. For Process Patty and Rabbit Hole Ray, the problem with the two of them is that they are not effectively managing their time. For them, they need to start working on prioritization. What’s most important to do right now? Job Security Jim and Conference Connie both need to be open to learning new things and be open to trying them out, not the expert for a little while, while they are trying those things out.
Matthew Heusser (27:45):
Okay. Thanks. Michael. Do you have any thoughts you wanna wrap up with?
Michael Larsen (27:50):
Sure. I think honestly, every one of these should feel maybe just a little bit familiar to us. If we walk through these and say, “None of those apply to me,” either you are a really rare unicorn or you are deluding yourself. It requires some self-awareness. The nice thing is that if you have bad personas, you can change them to be better personas.
Matthew Heusser (28:20):
Yeah. My only thought is that a lot of this boils down to, “just tell me what to do and I’ll do it.” And management wants to reduce risk and the way to do that is to have a repeatable process. To some extent, it’s kind of silly. It comes from not really understanding how to talk about, evaluate, or measure risk. So once we start pulling on that thread of how to explore risk, that’s when I think the fun part start to happen. And we can communicate in ways that are measurably better than folks who just wanna follow a process and be told what to do. I don’t get philosophical very often, but there’s a wonderful little free movie on YouTube called Finding Joe, which is about turning your life into the hero’s journey. And with that, where can people go to learn more? Kristen, are you speaking anywhere? Tell us more about the book.
Kristin Jackvony (29:09):
Sure thing. The book is called “The Complete Software Tester: Concepts, Skills, and Strategies for High Quality Testing.” It is available on Kindle through Amazon. You can also find, I have a LinkedIn learning course called “Postman Essential Training”. And I also have a blog that I write in regularly, which is “Think Like a Tester”. And you can find that at https://thinkingtester.com. You can also find me on LinkedIn and other occasional social media ventures.
Matthew Heusser (29:42):
Thanks Kristen. Michael, what are you up to lately?
Michael Larsen (29:45):
Well, let’s see. Conference Michael (laugher) is going to be speaking at the combined STP.con at Inflectracon that’s happening in may. It will be happening in Washington DC. I am hoping to be there in person. We shall see if the current unpleasantness allows us to do that, but watch this space.
Kristin Jackvony (30:09):
Thanks, Michael. I will add conferences have changed my professional career. They have connected me to some amazing people and you get to kind of reset. If you get a chance to go to conferences (now that they’re free and they’re on the internet) the one thing your boss knows when you come home is that, “you lost two days to a week of productivity and some money.” So try to have three things that you can do that you need no one’s permission for, that you do not need to buy a tool to use, that you do not need to hire anyone to do. And that’s how you justify going to the next one. And that’s our show folks. Thanks for coming, Kristin. Thank you, Michael. We’ll see you again soon.
Michael Larsen (30:54):
Thanks for having us as always.
Kristin Jackvony (30:56):
Thanks.
Michael Larsen (OUTRO) (30:57):
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, Google Podcasts, and we are also available on Spotify. Those ratings and reviews, as well as word of mouth and sharing, help raise the visibility of the show and let more people find us. 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 thetestingshow (at) qualitestgroup (dot) com and we will send you an invite to join 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. Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to be a guest on the podcast, please email us at thetestingshow (at) qualitestgroup (dot) com.
