In this interview, Mary Thorn of Ipreo explains how to get the most out of your team's test automation strategy. She explains why you need to implement automation, the balance between manual and automated testing, and what to do when a team's automation completely lacks a strategy.
Josiah Renaudin: Welcome back to another TechWell interview today. I'm joined by Mary Thorn, the director of software test engineering and agile practices at Ipreo and a keynote speaker at this year's STARWEST conference. Mary, thank you very much for joining us today.
Mary Thorn: Thanks, Josiah. I really appreciate it. I'm looking forward to having a conversation.
Josiah Renaudin: Absolutely. Before we do dig into that conversation about your keynote, could you tell us a bit about your experience in the industry?
Mary Thorn: Yeah, I've been doing software test engineering for about twenty years. I've done agile software test engineering for about the past ten. I've crossed multiple domains, primarily HR as well as financial domains, and that's what Ipreo's is, a financial technology company. A lot of work at startups, so I have a real passion around building software test practices from scratch.
Over the years, I've been in a position where I've come in for startups, built their teams from scratch, and then, a lot of times, they move from a waterfall environment to an agile environment. One of my passions is, I've seen a lot of different agile implementations because of that, and that allows many different tooling options, and because of that, I've gained a lot of experience on transformation and agile testing, and that's really what has inspired me around my keynote that we're talking about today.
Josiah Renaudin: When I first started doing these interviews, agile was always a point of conversation, about, like, "Does everyone need to do agile?" Automation has also been one. Automation at the start, when I first started talking to people, was more like, "Do you need automation, and where do you need automation?" But are we at a point where test automation isn't optional but actually required within a modern software team?
Mary Thorn: In a modern software team—so if you were saying agile versus waterfall, even in a non-waterfall environment, it's still essential. There's so much return on investment that you get from having things automated, anywhere from quick feedback around broken code, allowing the manual testers or maybe your more domain testers to be able to actually do really good, in-depth testing, other than just making sure the happy path works, helping with the build and deploy process and being able to really quickly make sure that what you're getting into your environments are in a good state because they were able to pass the automation. There are just so many benefits that you get and risk reduction. I always ask people, "Give me a couple ways to reduce risk in agile," and they first always say, "Automation," and that is primarily the goal. Automation is, to your point and your question, it is ultimately the, in my opinion and everywhere I will be in the future, required to take that software practices to the next level.
Josiah Renaudin: I often hear about the balance between automated and manual testing and how you can't fully rely on one. You can't only be manual, and you can't only be automated. In your mind, is there a universal ratio that works for the majority of teams, or is it one of those situations where it just depends on the makeup of the organizations and the projects being worked on when it comes to your balance between automated and manual testing?
Mary Thorn: That's a million-dollar question. It's really interesting. This market keeps changing. Five of six years ago, you had the whole "Software testing's dead" thing that went through, which was like, "Manual testing's gone. Everybody has to be automated, so we're just going to hire developers to do all the work." Over my past twenty years, I believe in the craft of software testing, and I do believe there is value that manual testers bring, for me, either from a domain user experience perspective versus somebody who's just a straight automation person. Best case, you really want a person who can do both. They have this concept of full-stack developers. They can do front-end work or back-end work or middle-tier work. With testers on a Scrum team, somebody who can write test cases, who understands the domain and use cases, who can do the automation and code in C# or Java, that's maybe the unicorn.
That's what you want, but when I walk into organizations, that's rare that I find those people immediately. What I do is I look at a Scrum team, I look at the skill sets of those testers, and I'll say, "This person's a twenty-year product expert who maybe is now being given to me from a testing perspective. It is imperative that I upscale that person to learn C#? The value that they bring by her or him learning C#, is it really going to help this Scrum team?" Sometimes, it does. Sometimes, it doesn't.