Mission-Critical Test Automation using Cycle Labs with Josh Owen and Andy Knight

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey it's Joe and welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Josh Owen and Andy Knight all about mission critical test automation, all other kinds of topics. Especially with enterprises when you're really dealing with really complicated end to end type of testing, we have to test more than a browser. So if you don't know Josh Owen is the CEO and co founder of Cycle Labs and prior to Cycle Labs he also founded and led a global supply chain consulting firm through 12 years of organic growth. So he really knows the industry that's really complicated as well as starting up a business that I'd like to dive into that goes around testing these types of environments. So really excited about that. He has over 17 years of experience with deployment or deploying enterprise solutions across various industry vehicles or verticals and JOS is dedicated to modernizing enterprise solutions, deployment and helping companies focus on business growth rather than business risk, which I think a lot of people miss out on when they focus on testing. And like I said, is the founder of Cycle Labs who encourages clients and teams to question everything and strive for continuous iterative improvement, which I think everyone should do as well. And we have the one and only Andrew Knight, also known as Pandy. He is the Automation Panda. He is a software quality champion who loves to help people build better quality software. You've probably seen him speak at multiple conferences all over the place. He is the principal software architect at Psycho Labs and focusing on test automation excellence for supply chains and warehouse management. He's an avid supporter of opensoft software. You probably see him all the time talking about playwright, talking about Python and he's the lead developer for Boa Constrictor for the net screenplay Pattern. Everyone should be checking out the screenplay Pattern. And he also does a lot of writing. He's working on a book right now. I hear on software testing that he's going to be publishing with many publications. Hopefully I'll have him back on the show to talk about that. And apart from software, if you know Andy, he likes vintage Volkswagens. He's always working on them. You can check out his tech blog at handy@automationpanda.com and follow him on Twitter as well. Really excited to have him on the show. You don't want to miss this you want to learn more about enterprise type automation and stay tuned.

This episode of the Test Guild Automation podcast is sponsored by the Test Guild. Test Guild offers amazing partnership plans that cater to your brand awareness, lead generation and thought leadership goals. Get your products and services in front of your ideal target audience. Our satisfied clients rave about the results they've seen from partnering with us, from boosted event attendance to impressive roi. Visit our website and let's talk about how Test Guild can take your brand to the next level. Head on over to test guild.info and let's talk.

Hey Josh and Andy, welcome to the Guild.

Hey Joe, excited to be here. Really appreciate you having us.

Awesome. Great to have you. Hey Andy, good to see you.

Good to see you all as well.

Cool. I guess before we get into it, Josh, I'm always, whenever I have founders on the Guild, I'm always curious to know why they started their company, especially around automation and testing. So maybe a little backstory before we head into mission critical type testing topics.

Yeah, happy to do it. So, as you sort of alluded to in the introductions there, I've spent a long time, nearly two decades at this point, deploying what I would call enterprise supply chain software. And so, you know, the elevator pitch and what that is is when you think about a warehouse or a distribution center, it's a complicated process that happens within those four walls, right? So there's material handling, equipment, conveyors, robotics. These days you've got people management, inventory management, you've got printers and scanners and desktop applications. And so it's a complex environment. And what makes it even more complex is that you're sort of orchestrating the movement of tangible physical goods within those four walls. You're moving inventory and people around this facility. And so my first job out of college was working for a company that made this software. And I was on their implementation team. And so we would spend months, 6 months, 9 months, 12 months, sometimes multi year projects, you know, putting this, what's called warehouse management software into production to manage these facilities. And so after a couple of two or three years of working for the company on the implementation team, what we realized is there's a really big quality mess. So that's the short story, right? What happened, you know, sort of like cognitively in my head was we do these really long projects and I felt very passionate about the fact that we done everything that we knew to do. We, you know, solved the right problems, we built the right solutions, and then we would do what we call a go live or sort of the cut over to the new system and then, you know, all hell would break loose, right? We'd be like, oh, this thing's not working. And we didn't even build something for that. And after, you know, years of doing this and really, really painful go lives and lots of hours on site at a distribution center in the middle of nowhere, eating out of a snack machine, you know, one day we're kind of like, why does this keep happening, right? What is going wrong? When we spend so much time trying to prepare for this thing and then going live and there's issues all over the place, I say issues and I try not to say bugs. That's what we would often call them, right? It's oh, there's a bug in the system or something. But what we realized is it's, it's really a lot of times just rooted in miscommunication, you know, missed conversation in the projects or say one thing. We thought we understood a thing, but there was a lot of nuance there that if we'd uncovered it earlier in the project, we wouldn't have had those issues. But they, they eventually ended up on a bug list. So, yeah, after, you know, nearly 20 years of dealing with that, about halfway through that time period, we said, hey, I think this problem has been solved. I think it's been, it's probably been solved in a different context. We're not necessarily building software from the ground up here, but we have a lot of similar challenges. And I think if we take solutions that have existed for decades and try to apply them to this context, that might be a good place to start.

Love it. Yeah, I love domain knowledge. A lot of times people overlook domain knowledge and when you just have a tool that you're trying to automate, you don't have that domain knowledge. You really miss out. So it seems like it's really going to help people with that type of enterprise as well. I guess before we dive into, I want to learn more about the quality misses I want to bring Andy into the discussion. So Andy, looks like you have a new gig. I just want to know how you learned about Josh and Cycle Labs and how you get started there.

Sure. So cool thing is, we're both local to Raleigh, North Carolina. We met about five years ago because at that time I was just starting my Automation Panda blog. I was writing about VDD and. And apparently one day Josh stumbled upon some of my articles, looked up the contact info and said, oh my gosh, this guy's local, we should meet up. And I think he Emailed me through the contact form and said, hey, do you want to meet up for coffee? I said, how about we meet up for bubble tea? And that was the start of a beautiful friendship. And here we are now.

Yeah, absolutely.

Awesome. So it's interesting about bdd, Josh, because when I go to your website and I learn more about your company, I think you have like a behavior driven strategy, a focus geo testing platform. Was that before or after you met Andy? Did Andy inspire you or were you already doing it before Andy came into the picture?

Yeah, it's an interesting question. So truthfully, we started down this behavior driven path prior to meeting Andy, but I think it was probably searching for expertise on BDD and things like that that led me to Andy's blog. Yeah, so I think, you know, part of the appeal of that behavior driven approach to us was that, you know, we aren't building these software solutions from the ground up. We have these, you know, behaviors that we're trying to validate when it comes to deploying these systems. And so for us, that sort of approach or that sort of, you know, injection point into the process felt natural. We weren't building the solutions, but we needed to understand, you know, are the processes, the behaviors that you want from the software, you know, is the solution supporting them. And so starting with, you know, that natural language approach felt a lot more fit to us, to the context in which we were working than maybe traditional sort of like other unit testing or more granular programmatic type testings.

So andy, this was 2015, you've been, I guess, dealing with BDD for a while, still big believer or anything you see that people sometimes don't get right with bdd that maybe causes issues with automation. Let's step right into it now.

That's great. So I would say yes, I still believe in behavior driven development. I like to speak more of a behavior driven mindset. Some people get locked into specific rules and regulations or certain practices they feel like they absolutely have to do to a T in order to be quote, unquote successful. My view is that in software and whatever we're making, whether that's a web app or an API or some sort of workflow through a warehouse management system, we need to keep the behaviors of the system in mind first and foremost throughout the whole development and testing process. Why? Because it's behaviors that bring value. Right? Software is meant for people. Right. Nobody cares when they're using a software and what language is written or whatnot. They care that they can order their lunch for delivery or that they can see their bank transactions or that they, when they order their iPhones, they get them delivered. Like it's that kind of thing. And so it's. Software is empowering the processes of life, right? And so those are the behaviors that we build into the system that bring us value. We put that first and foremost in the focus of our development and testing. Everything else is going to fall in place. And so what all these BDD things are, are just practices to help us do that. So when we talk about things like example mapping, right, Trying to figure out what the behavior should be, or we talk about specification by example, the idea that we can clearly define what the behaviors are for both being a proof of purchase for development and a executable test specification that we could run and automate. That's what I believe in about bdd. And honestly, I can't imagine developing or testing any software without that kind of mindset. Whether you call it BDD or not, love it.

So, Josh, why did you select. I assume a lot of people maybe that are dealing with supply chain, warehouse type software don't necessarily want to be developing engineers. They have users that know that the flow of everything, how things should work, but don't necessarily maybe know how to program. So I'm just guessing, is that why you went with this type of approach?

Yeah, exactly. I think we looked at sort of the challenges that we felt needed addressing sort of in the context with which we wanted to build a testing solution. And I mean, I guess it's kind of a backstep into why did we build something in the first place, right. There are plenty of fantastic BDD tools out there. So what motivated us to go build something new? And I think for us it was like, we talk about it like this, right? So our clients, the people who use our software, they aren't building software in the traditional sense, but they are building software systems. We just say they're using larger Legos, right? So like they're buying enterprise software. These maybe a wms, maybe a labor management system or an ERP or a CRM or an hris. And you know, they're sort of building a software system by integrating these various things and putting them together. And then to complicate it even more, they may be extending them, modifying them slightly, putting their complicated data in it. And now this thing has become a system that needs validation on a regular basis because otherwise they become very stagnant. Right. Especially in the enterprise, it's very common for a culture of fear of change to be established really quickly. Because it is big and complicated and because the stakes are high when you introduce a problem, especially inside of a warehouse, when the conveyors aren't running, no one's happy. Right. So we needed a, you know, a software solution that could jump from technology to technology in a single test. Right. Very often in our world, a particular behavior will span multiple technologies, very often multiple vendors. And so we need to be able to run end to end validations of those processes. And so we needed to seamlessly jump across technologies. And we wanted to do that in a common language, you know, where you don't necessarily know. I've moved from C to Java to an API test or something like, I just want to understand the behavior that I'm validating. And so we needed something that worked in that context and we felt like behavior driven development or this sort of behavior approach to validation fit that bill. And then to your point, a lot of our clients, they aren't software developers, right? They're software users, they know their processes, they're passionate about the behaviors that they expect from the system, but they aren't developers. And so a natural language approach to sort of facilitating conversation. And so test construction, if you will, felt natural to our clients. Much more natural than say, cracking open, you know, an IDE and writing some code.

Absolutely. Now, I guess it tends to go with a lot of companies I speak with that have a lot of package based applications create the application with no code. So why would they use a coding approach? They usually like to go with a more no code approach, just like they go with the development for sure. So I'm just curious to know, how do you handle the jump then? I assume like you have scanners and maybe some robots and CRMs and all kinds of different technologies along this tech stack that you have to deal with, especially with warehouse and supply chain. So how does this software deal with it? Are you a wrapper on top of other technology or is it like proprietary software that you created that's able to handle all this different tech stacks.

I like to think of Cycle as the ultimate true integration testing tool because we have a whole bunch of systems that are integrated together that we're trying to cover. So a test case might walk through entering in something in a web browser, calling an API, going to a terminal green screen. And so we provide in CyclerScript, our domain specific language for test automation, out of the box steps and interactions that handle each of those kinds of interfaces. So you can truly have this end to end workflow covered through a whole system.

All right, nice. So I'm just thinking of keywords. Back in the day we'd have like a keyword and framework. Where would, you know, like log in, patient. Maybe if it was like a domain specific to a hospital, is it something similar to that? Then when someone's creating a test, you have like prepackaged steps or common scenarios.

Indeed, the best way that I could describe Cycle Script as a language is imagine cucumber on steroids, where all of the steps are actually given to you and you don't have to make your own. So at the very most basic kinds of tests that you would write in Cycle Script, you would say scenario colon, give it a title. Then you would have given when then lines to specify step by step what the procedure is doing to exercise the behaviors. And instead of, like I said, having to make up your own steps, we provide a library of hundreds of native steps for things like, you know, given. I load the Chrome browser when I navigate to this page with this URL and I click the button with this particular CSS selector and I do this and I do that. So it's all very plain language. I call it semicoded because it's not fully codeless in the sense that you have a recorder. You have like some sort of GUI builder, but it's not entirely coded either because you're not dropping down to Java or Python or whatever. You're not directly calling Selenium webdriver. You're working with these plain language steps that describe more of the interactions rather than the automated mechanics. And so you would piece together a test with those kinds of steps that are given to you. Right. You don't have to implement that yourself. There's some other cool stuff cyclescript does. There's some if else logic there you can have while loops, there's some other constructs, but at its core that's basically how you would write tests.

Nice. So I think with this type of software too, a lot of times you need to do validations beyond a web browser. So probably database validations and different types of business requirement outcomes, I assume. Does it have built in tech for that as well to help people get the right validations at the right place?

Yes. So I know that you can have some database calls. Worst case scenario, if you need to do something that's not provided by our steps, you can always drop into Groovy and just kind of script that off on the side. It's a little bit dirty, but you can do it.

Awesome. So Josh, you know you talk about deployment coming from a deployment background. There Anything special that the software helps to get that deployment happening? Does it help some automate tests? Is there any other functionality that helps them scale or get it out the door quicker or faster?

Yeah, I think so. So I mean, I think just back to the root of like why do we do things with this sort of behavior driven focus is I think there's a ton of value in just establishing better communication earlier in the process. Right. Just making sure that when you say pallet receiving and I heard you say pallet receiving and we write it down and we look at that process on paper that we're in agreement, that is the behavior that we want from the system. And you'd be amazed at how often you can find issues or just find that you don't even need some modification that you thought you needed. When you start to write this stuff down and get around a common language. Right. That sort of specification by example maybe sometimes helps us just decide we don't actually need that custom change that we thought we did because we were able to find that that behavior is already supported in some way. So there's a lot of sort of that maybe less quantitative value that you get by establishing just better communication earlier in the process. But as Andy alluded to, you know, when these documents then double as an executed specification or a test, then you've got this sort of like ever building library of behaviors that you can continue to validate. And the thing about I'm sure all systems, but specifically these production systems, is when we go live, that's not the end, it's really just the beginning. Right. So probably the next day we were going to introduce additional changes. And without that validation library, you may have two weeks, you may have 12 weeks of manual testing and validation and things like that before you can get that change back into production. And so for us there's a much faster time to value when on day two, you realize there's some other change that we missed, we didn't talk about or something, and now we can validate it, we can progressively test that change and get it into production faster. And so that's a big win for our customers. And they're always changing these systems. Right? And a change for us doesn't necessarily mean a software change. When you think about a business, you're thinking about like onboarding a new vendor, switching suppliers or updating your labels or whatever the case may be like. And all of these systems have high enough complexity that almost any change should warrant a regression test. And so there's a lot of value there and then I think, you know, loosely related to your question, I think is we also provide a means for performance testing. So what we'll find is that any particular process validated, sort of in a serial fashion does great things. Maybe it works perfectly fine. But when you start to run any kind of sort of concurrency around it, you can uncover all kinds of other issues, especially in these really high volume production environments. And I don't even necessarily mean like hundreds or thousands of concurrent tests. I'm saying sometimes just running 10 or 20 at the same time, one, you know, help us understand that there are database logs that happen when this is happening, you know, things like that. So yeah, so cycle as a platform not only helps us author these tests, but it's a test runner and executor as well. And so we can run those tests in volume and performance tests at scale.

It's a good point about bdd, probably why I've used it as well is you want to get the clarity before you actually to make sure everyone understands what's going on before you assume what the test's doing. Because it seems like there's so many pieces that if you don't have it written down in a way that everyone can look at and go, well, you know, you missed this piece or you missed that piece. You probably uncover a lot of bugs before you even get to the development of the test script. Sounds like.

Yeah, actually. And it's, it's really funny because more often than not, if we're plugging in to help a customer that's like already up and running on a system that wants to upgrade or move to a different solution, they may have been running on some system for two years or 10 years or 20 years and no one person knows what success looks like for that process. It's not written down anywhere. Right. It's sort of this, it's living in some, someone's head or some combination of people's heads. And so like the first step is just like getting it on paper so we know what does it do today and what do we want it to do tomorrow.

So I love that. So it's almost like living documentation as well. So I ain't change then you're getting the benefits of not only a test, but new people coming on or I don't know if you have to deal with like audits or anything. Well, here it is. It's like plain English. This is what it's doing, this is what we touched, this is what we.

Entered exactly in our space. You know, a lot of Times when you're going through a big project like this, you know, there's a lot of reason to write all that stuff down. But what happens is if it's only valuable for that one go live, there's no motivation to keep it up to date. Whereas if it's a living documentation, if it's validation and you're using it for regression testing, then there's a lot of motivation to anytime you're introducing a change to going back and make sure you're, you're keeping those up to date. And so we're giving them incentive to keep these documents up to date where in the past they're a lot of kind of like one and done. We'll do it in a word document, but then never touch it again.

Absolutely. So, Andy, I don't know if have you done anything with the performance testing piece? I'm just curious about the performance testing tech, how that works. Could you reuse like a standard test? You have already say, okay, Dan, now it's a functional test. Let me up it to 10 users and I can easily scale it up.

So I haven't yet gotten to play with that in the platform.

Gotcha.

But I think, I mean, Josh, correct me if I'm wrong, it's more of just in how you would organize the scenarios to be run. Right. It's not like there's a special construct for it.

Yeah, that's right. There's essentially an interface that allows you to take any particular behavior. And then sort of, as you alluded to Joe, they're saying, how many instances of this would you like to be running and you know, which processes you want running at the same time? Of course, like with any performance test, the complication there is to make sure the data that supports the test is in a, in a good state. But the idea is to be able to have reusable assets, use the behaviors both in regression perspective and a performance perspective.

Nice. So I assume also when you're trying to deliver mission critical software, you need to make sure everyone's on the same page. So using BDD to make sure everyone can see and understand what's being tested is a big benefit. Do you have any sort of dashboarding where like an executive or someone can look at it and say, okay, this is go, or this is a no go?

Yeah, absolutely. And I think, you know, reporting is funny because no matter how much you think you've gotten it right, every single client wants something slightly different from it. So the approach we've taken thus far is we do have Standard readable tests that, you know, say here's the test you ran, here's what the application looked like along the way, here's green, here's red, if it is red, here's what it looked like when that happened and all that good stuff. But we found most enterprise customers like is just for us to be able to stream those results to some type of BI tool or some centralized place where they're looking at trends and things like that. And so they've got a lot of dashboarding tools they're already using. And so we can stream all of our results to sort of a meaningful place for them and they can use their dashboards, their beyond tools, so forth and so on to slice and dice things and expose it to executives in a way that's meaningful to them.

Nice. So Andy, what's your role going to be? Are you going to be consulting where you go on site to help people make their automation efforts better, or are you getting up to speed on supply chain testing? Any special things that you need to be aware of with automation as it applies to supply chain testing?

Sure. So my role will be the principal software architect, very much more on the product and engineering side rather than implementation services or consulting. My role will be asking the question, where does cycle need to go in the next five to 10 years? How do we build the product and the services in order to get there? So right now, Josh and I and others in the company are working on a product vision for what the next generation platform will look like. It's pretty exciting stuff.

Is it Python based?

I don't think so.

I could do other things in Python. It's all good.

I know, I know.

But one of the big things we're looking at is building a cohesive system so that folks can design and develop and execute tests from inspiration to implementation, rather than just narrowly focusing on just automation. Right. I know a lot of everybody who is testing software systems has to go through discovery, formulation and automation. Right. But what we have seen is that many of the tools and platforms kind of have a very isolated view. They only attack one of those phases. What we hope to do is really have a cohesive system that makes it seamless to do all of these together. There's other cool things that we're looking at as well, but that's just a bit of a taste.

Yeah. One of the first things we had Andy do, Joe, is just spend time with our implementation team. Right. Just like go sit down and say what works for you, what doesn't, what pain points do you have. And that's a lot of where some of this vision stuff comes from. And as Andy alluded to, we're pretty excited about it.

Awesome, awesome. So, you know, I just want to follow back on. One of the first things you mentioned, Josh, was quality misses, especially with the supply chain. If someone's a tester and they just, they have to start dealing with supply chain type automation, what are some those quality misses you think they should maybe focus in on? Are there some key ones that you think people, Is it performance? Is it, what is it?

Yeah, I mean, for us, you know, because there's a physicality to it. There's a really wide swath of like different quality buckets, I think. I mean, certainly we never think about sort of the software delivery life cycle in the space which we work. Right. We are building these software solutions so there's a vendor somewhere and so we take for granted. Let's just assume that whoever is building the solution that they're selling to this customer has done all the unit testing that they should do. Right? So we try to shy away from things like unit testing because, you know, at that point it's like we're, there's not, we're not adding a lot of value there. You hope that your vendor has provided you quality software that does what it's intended to do. The real question is, does it continue to do that in your ecosystem once you've established all those integrations and modifications and things like that? So much more of a functional approach to validating the behaviors and things like that. And so there is regression testing for those examples that we talked about before. There's acceptance testing. And we would never suggest replacing uat, but we can certainly supplement those processes by saying, hey, bring your super users off the floor, bring your business people in, have them lay eyes and hands on this stuff once, you know, sign off on it. But now we can validate that same process going forward if it's unchanged. Right? So we can, we can supplement, you know, those UAT processes by saying instead of going back and having your users touch everything again, have them put their hands on the changes. We'll validate everything they've already signed off on from an automated perspective so we can support a faster UAT process. Then of course there's going to be a performance testing phase. Then another phase we just, we don't touch is in our world, there's a lot of physical testing that must take place. The conveyors have scanners. They need to scan these labels and make sure that, you know, the boxes are being diverted down the proper lane and we don't, we don't validate that for them. But what we can do is make sure that when they show up to do that physical test, that they aren't going to run into some, you know, crazy system problem that keeps them from accomplishing that validation. So we can supplement these sort of physical mock go lives by saying you don't need to bring a hundred people in. We can run these tests at volume. You need to bring in one person to test this physical process, and that saves them a ton of time and money instead of having to do it all in one big physical test.

Love it. And I assume also if they're using packaged applications, maybe they make an assumption, hey, it's already been tested, why do I need to test it? But like you said, when you put in your own flows, you need to test your flows to make sure they're working correctly.

Yeah, exactly. And so sort of our, a way that we go to market is through strong partnerships with the OEMs that the companies that build these software solutions. Right. So what we'll often do is build prepackaged libraries of these behaviors and automations because a lot, you know, every warehouse, although they oftentimes look at themselves as significantly unique and different, there is, you know, in the Venn diagram of where they overlap with every other warehouse, there's a pretty sizable overlap and there's no reason to reinvent that wheel every single project. So we can have a lot of economies of scale if we pre build libraries that we know are going to provide 75, 80% coverage of these processes. And so we'll build these libraries out in partnership with the OEMs to build the software that helps us get up and running faster. Then all we really have to do is sort of do that behavioral gap analysis that says, how does this process differ from the way that you guys do? It will upfit our standard features and tests and, or sort of off to the races.

So, Andy, I'm just curious to know, you know, if you're dealing with a lot of not weird technology, but technology that sometimes you think you can't test. I used to work for an application that did radiology and you had to look at the X rays and you're like, oh, it's untestable, you need to do it manually. But aha, we found visual testing could actually handle it. So have you seen any of those examples maybe that you people may overlook when you come to maybe this type of testing, that visual validation, testing Things could help?

Oh, absolutely.

With things that maybe seemed non automatable.

Yeah, because I mean traditionally when we look at any sort of UI testing, it's always hinging on some sort of anchors on the page or the markup of the structure. What visual validation allows you to do is look at it as if you have human eyes. Like, oh, you can track things implicitly like color, layout, size, position very easily by taking a visual snapshot and comparing over time. I mean there are many visual validation tools out there. I mean, many of y' all know I used to work at applitools, so that's. They were one of the best in my opinion. But it's. You can have these large kind of visual validations where maybe you take a whole snapshot of the page. But there's also other little tricks you can do with visuals as well. For example, maybe you want to use a visual locator rather than an XPath or CSS selector. Just do pattern matching for that versus maybe performing an assertion on it. So there's advantages there as well.

Nice. And this may seem like a crazy question. I know I used to work for an insurance company. They still use mainframes. So Josh, how common is that? And does this application or this solution help with even mainframes? Like what does it handle? Does it handle that type of technology as well?

It does, yeah. Maybe you wouldn't be surprised. But I'll say it anyway. You'd be surprised how many warehouses are still powered by IBM I or as 400, you know, mainframe type technologies. And again, I think that's at the root of the problem we're trying to solve in our space. We tend to, you know, at the service level we're, we're solving a quality problem. But I'd say like our bigger picture purpose in this space is to get them moving forward, right. Getting off of these old systems and actually upgrading the newer technologies. So we, our strategy is we're going to go back and meet them where they are and we're going to provide validation and confidence so they can introduce change into their system and, and then we're going to pull them forward with us and get them upgrading regularly and modifying and innovating because that's better for them and it's better for us and it's better for everybody if they're actually running on newer innovative technologies. And so yeah, we have everything from like built in terminal emulation for AS 400 stuff to the like, latest, greatest, you know, web technologies and API testing and everything in between. So, yeah, see, what we hope to do is give our clients this confidence to start upgrading and to change regularly so they can actually move forward. It's really funny because you'll go in there and you say, I mean, but why are you still using as 400 to do your, you know, to do this work? And they're like, well, it gets the job done. I'm like, that makes a ton of sense as long as the job to be done hasn't changed. But I think if there's anything we've learned, especially in the supply chain space, is the jobs are changing. Right. I mean, over the past three years with the COVID stuff, obviously supply chain has become like a, you know, a boardroom conversation. And so it's like, actually, there's a lot of improvement to be made here, and the job to be done has changed dramatically. And so you need to upgrade your tools to account for that.

Yeah. I don't mean to hop on it, but using the BDD style, I guess, would help get that clarity on the requirements. Say, look, you have a mainframe call here that you may not have known about, but once we documented it, not only is it a test, but now it's documented. Maybe we can replace this test at some point.

Exactly. Yeah. Again, the whole framework within which we work around behaviors as a focus just helps us have better, meaningful conversations around things. Just like that.

Love it. So, Josh, who's this for? I mean, this tooling for everyone and every company? Not one. I don't believe one tooling is bad, but maybe there's a tool that fits best for certain companies, certain situations. So someone's listening to this and like, oh, I need to learn more about Cycle Labs, like, who is the perfect customer or user of this technology?

Yeah, well, first and foremost, I think sort of psychologically, they need to be a customer that values change.

Right.

They want to introduce change. Because otherwise, what value does test automation provide? Unless you're planning on making changes in your system? So if you. You are one of these customers, like, we plan on running on the S400 for the next 30 years, then I'm not sure we're providing a ton of value. But if you're like, hey, we run on this now, but we'd love to get into something new. I think cycle could be a really interesting solution for you, and especially if you're not building your own software, if you're a company that's powered by solutions made by other vendors or even other parts of your organization, but you're just using the Software, then I think cycle could be a good option for you.

We mentioned supply chain with COVID and how there are a bunch of issues. I don't know, were any of those issues related to testing or not testing properly to anticipate some of these issues, or could testing have uncovered some of these things that people all of a sudden faced when Covid came into play and messed up the supply chain?

Yeah, 100%. And so, I mean, essentially what you find is in the supply chain space for the past, say 20, 30 years or longer, efficiency has been measured by taking processes that we are known to be standard splashing processes and squeezing the most efficiencies we could possibly squeeze out of them. Right. Just always doing it better, doing it faster, doing more of it. And there's this concept of just in time inventory, of like we don't keep inventory in the warehouse because it's expensive to have inventory there. So we're going to order inventory when we need it and things like that. So you've got these really, really rigid systems that are designed to be incredibly efficient. But I think in the supply chain space, when we realize is, oh, we now need to change and we need to change fast, that rigid system is actually the opposite efficient. So now you can't change, now you can't go get a different vendor and things like that. It's been so optimized for this one particular path. And so I think in the supply chain space, what they're realizing is there's a new definition for the idea of efficiency. Efficiency is actually a balance between sort of like doing it well and doing it efficiently, but also having resiliency and flexibility. So, you know, the ability to pivot, to adjust, to move, There's a lot of value in that. Not just we do this better and faster than everybody else.

All right, Josh and Andy, before we go, is there one piece of actual advice you can give to someone to help them with their mission critical automation testing efforts and what's the best way to find, contact you or learn more about Cycle Labs? I'll start with you, Andy.

Sure. So a piece of actionable advice. I would say don't overcomplicate things. Right. Focus on the behaviors you're trying to cover individually, atomically, independently, that will lead to much more successful testing.

Yeah, I think Andy's was fantastic. I think for me it's, you know, if you're working at, try to get a handle on what the culture is where you are. And if you think you're working in a culture where, you know change is a problem where there's a fear of change or things like that. You can be that catalyst, right? I mean, it takes someone to start it. You can be the one who says, hey, I think there's solutions out there to solve these problems and I think if we do these things, we can move the business forward. So someone's got to start it. Someone's got to make the noise there and you can be that person.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a464 and if the show has helped you in any way, why not rate it and review it in itunes? Review reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 I of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.