Panelists
Automation is a key component of most software development initiatives. It’s not just for testing, it also figures into the build process, Continuous Integration (CI), and Continuous Delivery (CD). To that end, having a stable automation framework makes a lot of sense but what exactly goes into making that framework? Today, Matthew Heusser and Michael Larsen have a chat with Chris Loder, the “Rogue Automator” about where to start, what to include, and four specific areas every good automation framework must have to succeed.
References
Transcript
Michael Larsen (INTRO) (00:00):
Hello And Welcome to The Testing Show. Episode 109. Building Testing Frameworks. This show was recorded on Friday, November 12, 2021. In today’s fast-paced software development world, there needs to be a strategy for automated testing and part of that strategy is a software testing framework. That’s great but where do we start? To get some answers, Matthew Heusser and Michael Larsen welcome Chris Loder, QA Automation Manager with Upland Software, aka the “Rogue Automator” to talk about the nuts and bolts of building frameworks, maintaining them, and getting information that matters out of them. And with that, on with the show.
Matthew Heusser (00:00):
Thank you for that warm introduction, Michael, As you said, today we’ve got Chris Loder, the QA automation manager at Upland Software. Before he was at Upland, he’s done a lot of interesting things on the speaker circuit, been to a lot of the STAR conferences, was an automation specialist at Halogen Software. Was at IBM as an automation lead, and that was because IBM purchased Cognos, where he was in QC and automation. I think that’s where the story starts, right?
Chris Loder (00:33):
That’s where my automation journey starts. I can even go back a little bit further. My actual test automation, sure. I started my IT career working at a mine in Northern Canada, an iron ore mine up in Labrador. So I worked in the IT department there. Basically, small application development is the group I was in and it wasn’t until I got into test automation many years later that I realized I actually kind of started automation back then and it was more like process automation. So I helped out, I built processes for the HR department, automated processes for the test lab that was there and that sort of thing. When I left Labrador, I moved up here to Ottawa, Ontario, Canada. I went looking for work and Cognos needed a tester. So I went to work there and realized I’m not that great a tester, but I’m a pretty darn good coder and I just kind of taught myself automation. I’d work during the day and then automate at night. And then that slowly kind of morphed into now I have a job as an automator from tool to tool to team to team. Eventually Cognos was a business intelligence software. We did a lot of cool reporting and things of that nature. I started working on the pre-packaged data marks, which was kind of neat. They got bought by IBM and just kinda kept growing from there. So spent some time at IBM as an IBM-er. And then Halogen came calling, asking if I’d be interested in coming to work there. I like to think I always go for a career opportunity. I thought it was a good one at Halogen. They needed someone to help them revitalize their automation. At the time, it wasn’t in the greatest of states. Spent a bunch of years there, then kind of similar thing happened, Ingenious needed someone. They had tried automation a couple of times. Hadn’t quite been successful with it. I came in. Very happy to say we have a very successful and robust automation there now. And then a couple of years ago, we got bought by Upland software. We went from a small company of 50 to something about like 500. So now I have more than just Ingenious. I have a couple other products that I make their automation for them. That’s my automation life in a nutshell.
Matthew Heusser (02:35):
Okay. Let’s dig into some of those details. So you’re the automation manager at Upland now. How big is your group?
Chris Loder (02:43):
I am one small part of a pretty big company. So right now I have a team of five. I’m kind of the, a bit of a pilot project because there are a lot of products at Upland. A lot of them have their own automation. Some of them have none. When Upland bought us and I did a few talks on what automation we have and how it works, other teams wanted it. So we kind of pulled me and my core team out of Ingenious and said, Hey, let’s make this central group. And then we’ll just do work for other teams. So I have a couple of core framework people with me. And then we have people who sit on the other product teams. They write the automation. So I have automation developers solely for ingenious, and then they report into my team and then we do the same thing for Right Answers and Simple and so on.
Matthew Heusser (03:32):
Okay, we’ve been doing this a long time. Today we wanted to talk about automation frameworks. What makes a good framework? What is a framework? And maybe we should start there. As you mentioned, you’ve got a company with a whole bunch of products and you are responsible for some percentage of them. And that percentage is growing over time. But in your words, what is an automation framework? Why do we need it? Why can’t we just buy SmartBear and use it and be done?
Chris Loder (04:00):
You can. Absolutely, you can. That is a framework unto itself. But I look at a framework it’s more than just the tools you’re using. It’s all those utilities and processes that you put together. It’s the people and the processes involved in them. All of that, in my world that becomes the framework. It’s not just the lines of code that execute tests. It’s all of that from the people to the environment that it runs onA all of that in my role, that’s my framework And that’s what I’m responsible for. And then that allows us to hopefully deliver better quality software faster.
Michael Larsen (04:32):
If I can jump in here real quick, a couple of years ago, I did a talk about how to build a software testing framework from scratch… Using spare parts. And that was sort of the whole deal. I think what I’m about to describe may be something very familiar to some people. And we’ve already talked about the idea that yeah, you can buy SmartBear whatever, and you’ve got your environment. The current environment that I work in right now, we use Virtual Studio and we’re doing stuff that relies on whatever.net we’re at and C-sharp et cetera. And Visual Studio does all that type of stuff. But one of the things that I talked about was for people who don’t really know how pieces fit together or what you want to do, it’s very common to pull down the Java Software Development kit, pull down Maven, which is a tool that you can run and you can bring it up inside of like a little browser window. And you can grab little components that can piece together. So you can run your test. You can write your tests, you can format your tests. You can do all sorts of reporting if you want to. And you can actually put together with not a lot of work, surprisingly, a framework that you can then extend and do what you want to with it. So my question is how common is that process that I’m describing versus say, getting something off the shelf and running with it?
Chris Loder (06:00):
It’s actually pretty common. A lot of people like to build their own and in your case assemble their own. I’m definitely in that world. Mine is built from the ground up. Again, Visual Studio and C-sharp. It is very common. I see it a lot. When I go to conferences and people come up and they talk to me, well, these are all the pieces we have. How do we put them together? How do we make it work? Ultimately for me, there is no good tool. There’s no best tool. It’s you take the pieces that work for you and work for your product and you find those and make those work together. And then like you said, you extend on. I don’t have a whole lot of pieces in mine. We actually wrote most of what we have in ours because we needed a custom runner. So I couldn’t even use something like N-unit or anything like that. Our situation was a little different, at least for Ingenious. We had to be a little more creative in some of the setups and things we did. But yeah, it is very common with actually looking at someone else’s framework right now, trying to see what’s involved in migrating it into ours. And he brought down pieces from the internet, hodgepodge them together. And it’s a fully functional framework. It’s kind of neat how we put it all together, but it’s a lot of moving parts.
Matthew Heusser (07:08):
Well, you mentioned a couple of things in there. If I buy… No disparagement to any vendor, but if I buy SmartBear TestComplete, I’m going to get a GUI Test automation tool, the tool is not going to magically run itself. Someone’s got to click “run” on their desktop and they’re going to wait for it to run and they can’t get any work done while it’s running. There’s no comparison of today to yesterday. We’re going to have to, if it’s a web based application, we’ve got to push the code to the website. We’ve got to set up the data. If we run it twice in a row and it corrupts the website, it’s going to call a search and find twice as much as it should because we added the thing twice. So clean up, data set up environment, set up, getting the newest version of the code, pushing the code, looking at the results, graphing the results over time. When I talk about frameworks, like I don’t know anything. I don’t know any commercial tool that really does it all. I mean, I guess in theory, I guess you could do it all with Sauce Labs, but you’d have to use a bunch of open-source tools. I’m trying not to leave anybody out.
Chris Loder (08:23):
There is no all, all encompassing one box size fits all. I’ve never seen one.
Matthew Heusser (08:28):
I think in theory, you might be able to buy Tricentis products and you might be able, they would have grown through acquisition and you’re still really assembling different commercial products together to get that. And I don’t know that that gets you everything that you want. So you’re going to have to build it.
Chris Loder (08:46):
Something has to get stitched together, for sure.
Matthew Heusser (08:47):
What are the pieces that when you put them together combined with an overlay of process, you can say, ah, this is going to work for me. And what is our goal? Why do we need it?
Chris Loder (08:58):
Yeah, I mean, for me, I, when we start to do our automation, my ultimate goal is I like to say, who should run the automation? Well, ideally, no one should have to run your automation. So I like to hit into it with, we wanted to make this as unattended as possible. I know tonight at six o’clock, we’re going to pick up the newest build. We’re going to uninstall it off our servers. It’s going to install the newest build. It’s going to set up our data environment and create our orgs, import the data. Then it’s going to do a status check to make sure everything’s alive. Then it’s going to run the automation. And then it’s going to generate my report so that I have results in the morning. It took us a number of years to get all of that together, we started with a core engine and added on. The least human effort to run it the better no one should have to babysit your automation.
Matthew Heusser (09:45):
So what we want to do is we want to find the repetitive human tasks that can be done exactly the same every time and hand them off to the computer. Those include the things you just mentioned. So version control, a build artifact produced by a continuous integration system are things that probably have to be in place for us for this to work. Like you say, you could just press run and sit there on your lunch hour and watch it. But if you’re doing that, you don’t have what I would call a framework. You’ve got a tool, you’ve got a chainsaw or something. And I’ve said this before with test automation frameworks, you want to get something more like a robot that goes and chops down the trees in the forest for us and cuts them up. Would you agree that some companies have a type of product mix where it makes sense to have left to right press a button, get results? And far left edge is human beings. Do everything. Some companies, their ideal mix should be somewhere in the middle.
Chris Loder (10:49):
Yeah. I only have that fully unattended right now for one of my three products. And that’s only because that’s the one I started with four years ago. We’re just bringing the other ones in. So now I’ve got Right Answers. It has it’s status check done, and it’s reporting done and it’s running done, but putting up the new site and all of that, I’m reliant on someone else for now. Hopefully it get that automated eventually.
Matthew Heusser (11:09):
And that makes sense to me. Usually we start with the low-hanging fruit, where’s the most value add and move out once it’s proven,
Michael Larsen (11:16):
Maybe for a number of people. I assume that if people are intimately familiar or who have done some automation for a while, they probably already know a lot of this or they just take it for granted. But let’s say somebody who’s listening is relatively new to automation or is getting their feet wet or wants to get involved in automation. And the framework conversation comes up. They want to either participate or you get somebody like me in various roles that I’ve been in, where I’ve been that lone person. I’ve been the lone individual responsible for coming up with an automation test strategy. May not be able to rely on the developers may have to come up with something on my own. What would somebody like me, the hypothetical newbie coming into automation say, I need to put a framework together. So I guess the question that I really want to ask is what pieces do we need to care about and become aware of if we want to either build a framework or be part of the conversation of what the framework is going to contain?
Chris Loder (12:24):
That’s a good question. Kind of where to start. I like to ask when I come into an area, what hurts the most? Like the QA folks, they know what the biggest headache for them is. When I came into Ingenious, they do computer telephony integration. So for those guys, it was all the phone systems. Immediately, we started automating all the telephony tests for them because they were very repetitive place to call, answer a call, transfer a call over the various phone systems. So we automated those because that’s where it hurt first. So for that, I just needed an engine, an engine and then I bolted on the piece that talks to the phones. And then I bolted on the piece that has the reporting. And it just kind of grew from there. Or do you need to figure out where it hurts first? And then from there decide, okay, well what’s the first piece I need to solve that little riddle. And then you just add to it. Is that the answer you’re looking for?
Michael Larsen (13:15):
Yeah. Matter of fact. Yes. It, it’s a very good point. I appreciate that.
Matthew Heusser (13:19):
Can you give us some examples, Chris? What do you do first?
Chris Loder (13:23):
You gotta talk to the people who know that. I’m a horrible tester. I don’t know the content as well as my QA lead does. So when I came to ingenious, I sat down with an awesome guy named Andrew. He was QA lead and he walked me through, you know, we have all of these phone systems, here’s all their versions. We have all of these CRMs, Salesforce, Microsoft dynamics, all that. These are all their versions. Is if I do every one of my combinations, it will take one person 6-8 weeks to complete a full regression cycle. So this is I need help. And I said, okay, where does it hurt the most? And then that’s where we started. Was in on the phones. So now they’ve turned their regression turnaround time from six – eight weeks with about five people down to two with two people, because we took enough off their plate. There are certain phone systems they don’t even touch any more. We’ve automated them. They use the fringe case phone systems now, as opposed to those core ones they used to have to repeat.
Matthew Heusser (14:21):
Yeah, I was doing a consulting assignment once. We didn’t even measure it. We just talked to people about how they spent their time. How much of your time is on rework? How much is it on… 70% of the time it was data set up and it was all front end, gooey click, click, click, click, click. And it was all exactly the same all the time. So if we just built a little program, it took a text file and blew the data into the database, setting everything up. And we had some reasons to believe that it was right. We still probably need to test setup periodically. We could take that from 15 hours a week to 30 minutes. So no need to write the magical GUI that does all the things. And by the way, creating GUI tests is slow and painful for most software. I think it’s changing. I think for some of the new systems that are coming out, which we should do a podcast on, it’s getting faster to write GUI tests, but for any old technology, any more than five, six years old, it’s painful and cranky to write them. That was where the pain point was. So I think it’s a great point.
Chris Loder (15:31):
One of the things they used to be used as an in-house tool that was built alongside the product, they call it their telephony harness. They used it kind of as a backdoor into the phones. And that’s what the manual folks are testing. So part of our setup process was to bring everything down. So we actually brought that down and then we kind of turned that into a utility for them. So they had exe on their desktop that would go grab the latest one of those, bring it down, run some sort of 32 bit or 64 bit converter on it. I can’t remember what it was now. And then they’d have that fresh in the new one every day when they would come in, wouldn’t have to do it. So save them time, going up to Team City, getting the build, bring it down and extracting it, pulling up the tool, converting it. We did all that for them. Save them time. My job, I like to think of that, it’s not really there to automate. My job is to make other people’s life easier. Whether that be taking that regression off your plate or building you a utility. When I was at Halogen, one of the things we did, there was a lady who did the docs. She had about two weeks of release, generating the PDFs with all the translations, doing the merges, putting them all together. Used to take her about two weeks. So we put a job in Jenkins, automated all that for her then ran it in an hour, we saved her two weeks worth of time. At Ingenius, again, for docs, every release, our docs person would have to go through and pull in all the screenshots. Well we’re already in the product and we take screenshots when we failed. So we just flipped a switch in our framework so that you can take a screenshot whenever you want it. Then we had some students write some navigational tests that go through the product it takes screenshots for and store them. Now she had all the screenshots, so she didn’t have to install the product, put it up and get it up and running, do all the things and get the screenshots herself. We were doing that for her.
Matthew Heusser (17:16):
Right. The robotic process automation and the test automation space have so much overlap. I get a lot of people asking me questions about that. We’re doing these dual entry in these two systems, and we’ve written this code to test both of those systems. And we can just turn it sideways and type some things into a screen and do both. You said that you’re expanding good practices into a larger org that is grown organic. If you look at my writings, I recommend that for almost everybody, is it let a thousand flowers bloom wait a year and then see which things work and then create a community of practice around it and share the things that work and the things that don’t, I like experiments. But I’m sure in that process, because of the way bell curves work, you probably run into some monster frameworks that were junky clunky. I’ve run into some that take, it seemed to maintain that never find any bugs. I ran into some where they turn the framework off and nobody noticed. So it depends on what your goal is. It sounds like you’re more of a refactoring type. Let’s figure out how to fix it. So do you have any stories where that’s happened and what you’ve done about it?
Chris Loder (18:35):
Yeah. When I first went to Halogen their automation there… average test case length, 45 minutes. They had about 700 tests. If you’re lucky, 400 and some would pass. So the automation team was spending the morning after a run, analyzing the results. And I can’t tell you how many times we’d hear well, automation failedus . I hate that phrase. Automation didn’t fail. At least it shouldn’t. It should find issues in your product. Shouldn’t be the automation that failed. Should be product has changed. They had three people doing automation and not talking to one another. So they’d gone through silos. They’d done it their own way. Even though they were all still using the same tool, one guy liked it one way. So he was using keyword approach. Another one was just hammering it out. And I still have no idea what the other lady was doing. Yeah. I come into some of that and it was a case of how did this ever work? I’m running this now. And I cannot see how this ever passed. Those are always fun to figure out. Yeah, that one was fun. In the end, we threw the baby out with the bath water on that. And we kind of started over. It was using another tool that they were paying for. It didn’t really want to continue paying licenses. And I said, well, you know, I’ve used Selenium. Let’s give that a go. We built the framework from the ground up around it. And I built my frameworks with anybody should be able to sit down and write a test case in mind. So I like to use a keyword driven approach, but we still do it inside an IDE. All my test cases right now were written in C-sharp. But since you’re in Visual Studio, you get the context assist for free. So I GoToPageImOn.Action. I want to do for us ActiveCallPanel.placecall, and then you’d pass the phone, the MainCallPage.AnswerCall, things like that. So anybody should be able to sit down and write a test case in my world with a little bit of hand holding. My automation developers, they worry about the page classes and they do the automated tests. But ideally we can get any person to sit down and write it.
Matthew Heusser (20:37):
Yeah. You mentioned Selenium. And I think with selenium in particular, you have this idea of what is a test. The test is a test case , a test case is some amount of code, how much is the amount of code. And then we define how much the amount of code is. And then we say, gosh, we’re logging in a lot. We should write some functions. And then we ended up with in many cases, something like page objects, which is kind of what you were describing, where the test is a bunch of calls to these much more detailed bits of functionality that we can reuse the call, business functions or workflow things. Now we’ve got 15 tests. Do we run all of them? How often we run them? What does running them mean? Well, how do we report on them? When I say framework, those are the kinds of questions that I think a test framework answer. But I think you’re right. That that’s not necessarily what everyone means when they say the phrase. And there can be a lot of other things in there. I think Michael had a follow-up he wanted to ask.
Michael Larsen (21:41):
Yeah, I do. Here’s my question for this. And I think a lot of it comes down to maybe it’s just the mindset of where you’re at. And I can only approach this from my own point of view and framework and my automation strategy, if you will, is I like to start out with whatever I’m doing. Kind of like a scientist. I like to experiment. I like to learn. I like to figure out what I’m doing. And in the process of that learning, I figure out patterns that can be reliably looked at, figuring out something from the ground up you’re chances are, you’re not going to automate from step one because you don’t know where you’re going. And then you might have a lot of wasted effort. So you experiment with some things you’ll learn about what the product can do. You figure out the flows that make the most sense. And once you’ve got those down and you see where things fit, then you start to say, okay, I can automate that. Or I can use this piece here, or I can hook these things up and Hey, great. There’s a test. Now, realistically speaking, by the time you’ve got that all together, most of that experimentation and learning and new avenue approach has kind of been exhausted. So now what you have is a pretty elaborate verification system that you can run. And yes, if you’re running that in CI, to make sure that you can get everywhere you need to, you’ve built everything you need to, and you’re calling the stuff that you want to call and you want to validate that… That has value. Absolutely. But I guess the question I’m asking, where would you encourage somebody to say, where do you stop with the exploration and learning and start putting in the effort to automate something? Where is the sweet spot for that?
Chris Loder (23:31):
Well, I always tell people to start with a pilot, do a pilot project, pick that one or two little things that you want to automate and, exactly, you start to experiment. How’s the best way to automate these? What is it I want to get out of it and set a goal at the end of this, when I’m done, I should have A, B and C .by that, once you have your A, B and C, then you kind of reached that point of all right, I guess my experiments are over because I’ve got to where I need to be. Setting goals before you start. It’s pretty important and realistic goals. Don’t set off, you know, well, we’re going to automate everything and it’ll all be done by Christmas. No. And I’ve seen guys do that and make that offer. And then just looks horrible when they don’t deliver. When I started at Ingenious, we started building the framework, the very first few lines, we ran the same 12 tests for a few months, just ironing out the wrinkles in the overall framework and adding to it and improving it. We didn’t want to add in a thousand tests because if I made a mistake, it affected a thousand. So while it was small, we ironed out those wrinkles, we got the reporting to work right. We got the set up to work, how we want it. All of that stuff was part of our pilot project, which was the small set telefony test to start. That was our goal. And then when we hit the end of that, you know, these are all done and they work and we’ve got some reporting let’s get going. And then we just kind of ramped up from there. And if you look at my test case count, we have this long hockey stick kind of thing, where it’s just kind of a little bit, a little bit, little bit. And then it just takes right off. And our test case count, just crank right through, it was crazy. Set some reasonable objectives in your pilot that you want to, when you’ve hit that and you’re done, then your experiments are over. But part of that pilot project is all that experimentation. Which tool do I want to use? Do I want to use Postman to want to write my own? Do I wanna use WebDriver or who knows? What else is out there? Cyprus? You know, any of these other ones, you have to take the time to explore them all. Then find the one that you like. One that you think you can maintain. Your framework has to be maintainable. Don’t just go taking something. “Hey, that worked. I have no idea how I’m going to fix it if it breaks, but it worked.” That’s no good. If you spend all your time maintaining it, you’re not advancing.
Matthew Heusser (25:50):
Fantastic… and with that, Michael, you think it’s about time?
Michael Larsen (25:53):
Yeah, I think so. So Chris, of course, we always want to give the last word to our guests. If there’s like your elevator pitch to kind of sum this all up and also what are you doing and where can people find you is how we like to give our guests the last word. So over to you
Chris Loder (26:10):
Cool. I like to build frameworks. And if you want to build one, I have four things that I like to reference. It has to be maintainable. If you can’t maintain it, it’s going to die on the vine. It has to be reliable. It has to run. I don’t care if your tests fail. Automation and the framework can’t. It has to run successfully. Every time.It needs to be flexible, that it can handle changes and minor changes that it can react and not fall over minor things change. And it’s gotta be a reportable and you can have the best framework in the world. But if you don’t get any data out of it, that’s actually useful. It’s no good. So you want to get that out. Those are my four foundations. Likely folks with that. And if you’re looking for me, you can find me on Twitter @rogueautomator or rogueautomator.com.
Michael Larsen (27:01):
Awesome. Thank you so much.
Matthew Heusser (27:03):
Do you have any upcoming speaking engagements, Chris, or they have, they figured out who speaking of star next and all that stuff?
Chris Loder (27:08):
No, they haven’t. I’m hoping to be at STAReast. I won’t speak for Alison, but I’m hoping to be STARwest was supposed to be live. And I really hurt when we had to move that to virtual is we’re all kind of really looking forward to getting back in person, but it looks like we’ll be in person, unless things go sideways again in the world. I’m optimistic that I’ll be there to hopefully deliver my tutorials and work in the test lab. That’s the other thing we’d like to do with the test and conference at the test lab. Yeah. You get some robots for people. The test is always fun and there’s some games. I have a small mock automation framework that I built that I keep on the side there that like show people if they want to poke around with it. So that’s always kind of fun too. So hopefully we get to do all of that in May.
Matthew Heusser (27:53):
So I’ll be at Agile Testing Days next summer. And there’s a little conference, which I think I’ve plugged here before, which I really like. It’s the Kitchener Waterloo Software Quality Conference of near you. If they are doing it. No it’s called On Target. It’s the Kitchener Waterloo Software Quality Association. The official conference name is Targeting Quality. If you look hard enough, you can probably find two or three people that actually use that name. The rest of us, it’s the Kitchener Waterloo Software Quality Conference. In the summer, it got yanked because of COVID. I want to find out if they’re doing that next year and that might be a place for us to meet up. A thing I like about KWSQA is the audience wants you to succeed. So they’ll try to figure out how you were, right. Instead of some testing conferences, it’s figure out how they’re wrong.
Chris Loder (28:43):
Yeah. I’ve sat in a few of those. You’re sitting next to the guy who’s just sitting there chirping the whole time. No, that’s not right. Like, why are you sitting here if you’re just going to disagree with the guy?
Matthew Heusser (28:52):
I find that the European conferences, the Canadian ones have a little bit of an easier on-ramp plus you get the feedback. So I go there with my craziest, wildest, I don’t know if it’s fully baked yet stuff. And then when I’m done, it’s good enough that I could take it somewhere else. So that’s what I’m up to publicly. Not a whole lot, Michael, you up to anything new?
Michael Larsen (29:10):
Well, I mean, at this given point in time, it’s kind of the down season for me, at least the way that I schedule stuff. For the next few months, I’m not going to be doing much more than the podcast and writing gigs that come up. However, I did get… I’m spacing on the name of the conference, but it was reached out to me to do a conference in Washington, DC. next May. They specifically asked if I would do either my workshop or my talks based around accessibility. I thought, Ooh, this could be interesting. Sure. So I’ll put it in the show notes when that comes up, but there’s a good chance I might be speaking in the (USA) Nation’s Capitol sometime in May. And we’ll see how that rolls. Otherwise. I highly anticipate I will be actively involved in the Pacific Northwest Software Quality Conference planning. I’ve kind of filtered into that role to be able to help with that, which has been great. And I’ve enjoyed doing that and we’ll see what 2022 has in store for us,
Matthew Heusser (30:06):
Here’s hoping it’s a good year. Thanks for being on this show. Chris, looking forward to getting to know you better working with you, maybe.
Chris Loder (30:13):
Thanks for having me. I really appreciate it. It’s one of the things I’ve been wanting to do myself is kind of maybe start a podcast. So it’s kind of nice to see how you guys do it. It’s on my career bucket list of things to do. So this has been cool. Thanks for having me.
Michael Larsen (30:26):
We wish you well in that endeavor. And with that, of course, we’re going to say thanks for joining us and for our audience. Thank you for listening. And we’ll see you in a few weeks. Take care, everybody.
Matthew Heusser (30:37):
Bye!
Chris Loder (30:37):
Thanks, guys.
Michael Larsen (OUTRO) (30:37):
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.
