Planning, Design, and Development of Test Automation with Ramiro Millan

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Romero Millan, Director of Product Development, Test and Test Studio, all about planning, design and development of test automation. Romero has spent a decade at Telerec in progress and roles including project management, sales, engineering, test project leadership and much more. Really excited to dive into his experience of what he sees in the field, developing a real world application and what he gets for feedback from customers on how to plan, design and develop test automation. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step of from code to deployment. For Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey Romero, welcome to the Guild.

Hey Joe, thanks for having me. Appreciate it.

Awesome to have you. Is it that I missed in your bio that you want the Guild to know more about before we get into it?

No, I mean, I think the bio is fine. I spent a very long time in software. I was a software engineer for years before I moved over to the business side of the house in classic asp, so that kind of dates me. We were moving to Net, so that dates me. But I like the business side of the house more than the programming side.

Now. Why is that?

I like people. I like talking to people. And sometimes as a developer, you're talking to the machine, right? You're talking to people, to people through your code. But I like the technical side. But I just, I like the business side of the house. It just, it really, really intrigued me.

Nice. So as I mentioned, you do work for a vendor and you have a lot of experience as well. You know, when people hear about software development or testing or a test tool, they think of just testers. But I'm just curious to get your insight into maybe some collaboration, how it happens between developers and testers in your experience, and how maybe some sort of tooling can help support them. So any experience from your customers or from your actually in house development on how you can get developers and testers? Maybe on the page?

Yeah. I mean, you know the term tester, right? You've probably heard this from a lot of people and you probably Know it well, it gets kind of, it's a bit gray because it can be somebody who's like a business analyst doing testing. It could be a manual tester or somebody who's working, let's say off a test case on Excel, for example. Then you can have, you know, the term sdev, which was, you know, there, but like a technical quality assurance engineer. So the collaboration is interesting, right, because they're all really trying to solve the same thing, right? Some of them are working, you know, with frameworks and trying to get that test case. Others are working with black box testing, posting and see, you know, poking at and seeing what comes back. So you know, the collaboration is important because that quality engineer, you know, for example, may see the test case different than the business analyst who's actually working with the stakeholder or really driving that, so has more intimate knowledge. And you can't write, you know, test cases that are hundreds of pages long in order to get everything, you know, to get everything down. So that can be tested. Exactly. So the collaboration needs to happen. And you know, it can happen with tools like for example, not the blog art tool, but let's say for our tool you can actually have a ba non technical QA come in and create the basic layers of your test. So the full test case and then flip it over right to a developer and then they can be running C Sharp right in those tests, you know, language that they're working with and then they can kick that back. So it's from a collaborative standpoint, it allows them to work on the same stack of tests on the same test case. And even you can, since we work off the file system, you can install that, you can put that right into your source code so you can be working all together. So collaboration, yeah, it's important. We can support it. Other tools do too. But we do a really good job of actually bridging those gap between the technical folks and the non technical folks working in that same mission.

Nice. So what I've seen in my experience a lot of times for some reason is developers have their own ecosystem, like you said, so maybe you have C developers, they're used to using C libraries and such. How does that work with the test tool when sometimes maybe you have a test tool that a tester would gravitate towards and a developer wouldn't. Is there any kind of friction when you're going between the different roles of the, the different silos with the automation?

It can, I mean, for example, lots of times with Selenium testers, that's not going to mix well with non technical. You know, there's no way. There's some tooling that exists out there, but for the most part that's not going to jive very well. But for us, our niche, you know, it's the C Sharp developer, right? The. Net developer, that's the arena we want to play in. That's where Telerik has made a lot of money, had a lot of happy clients. So in there there isn't too, too much friction for us. Because I'll give you kind of an example, I obviously can't say names, but there is a large bank in the western part of the country that has a massive deployment of Test Studio and they also use all of our controls as well. They have a massive deployment of our control. So this team is working together effectively testing grids, which is something that they're extensively using. And.

The test of the QA engineer has the ability in our case to use a tool called a translator that's built into all our controls. And when Test Studio hovers over that grid, it actually allows you to see things that are only server side. Hey, this is a teller grid. I know how we got here. Let me give you some testing. That's all on the service side from the developer perspective, they can write some very, you know, very complex conditional statements, right? They can have that in order to run, you know, to run tests or maybe do a really complex data drive test off a database. The non technical QA may not have that knowledge, but they can actually stub out the test to the point where they can easily be picked up by the developer. So there's, you know, the friction gets a little bit removed with our product. But is there friction? I mean there's always going to be friction. I don't know if you've ever seen this. This is like meme from years ago. It's like a grid and it shows like what the developers think of the designers and what the QAs think of. I don't know, you've probably seen that it's till this day makes you laugh and I think of that. But either way, not get off topic too much.

So you just brought me back. I started my tech career doing tech support for Visual Basic. And a lot of times you have a certain field you bring in and sometimes they're custom fields or custom objects. So is that how Teleryx started? Is that you started building Componen and those components then were hard to automate or. And so then you had a solution and then it just grew from there.

Yeah, that's, you know, it started with Teleryc, started many, many moons ago, building controls. First ones were like grids and calendars and stuff like that. And they progressed different, many different libraries. And Test Studio actually came out through an acquisition. It was a company called Art of Test out of Austin. And this gentleman by the name of Faris created this framework while he was working at Microsoft, if I'm not mistaken. Hopefully got my facts correct there. And that became the Telerik testing framework in Test Stud actually sits on top of that framework. So it's a WPF application that's a GUI on top of that particular framework. And that C Sharp framework is the one that I mentioned that the developers are working with. And in my humble opinion, there is no better testing framework for the C developer than the Teller testing framework. It's a very complete APIs are very similar to Microsoft, so it's an easy tool for most developers to pick up.

I agree. For some reason there seems to be not as much tooling around the C Sharp ecosystem, even though I think it's a, it's a strong system. So it seems like this would be a great solution, like you said, for folks that are already working with Microsoft, C Sharp, that type of technology.

Exactly. Yep. That's, you know, that's the arena we play in. There's, you know, so many other testing companies and competitors out there. You know, there's so many of them. They're big, you know, you've probably heard of Cypress. Like they're growing at a huge clip and that's fine, let them do that. Well, we are, we're very good in the verticals that we're playing in. We're really well liked. Education is a huge vertical for us, given that, you know, the legacy of these applications. Like, you know, we were talking to the development team about frames, right? And you know, the support for frames and it's like, it's, it's so ancient. I'm like, folks, this, this is not going away. These SAP applications, these blackboards and all these things are not going away and they're riddled with frames. And for us, it actually, we do a very good job of testing that the framework has good frame support built into it and we just added some additional support for it because our customers, the need to use, need this. I mean, these tasks are very repetitive. Some of them even use our tools, almost like an RPA tool, which is, you know, another interesting market in itself. But they can do that with our tool as well.

So is it able to test other technologies or only WPF C type can does it work with Java applications or no?

So right now we only do WPF applications, you know, in our roadmap. If you folks ever take a look at it, if anyone listening wants to look at it. Telerik.com teststudio we are actually releasing full desktop support. So we see the desktop being cool again. Microsoft's making that big push with the desktop and from our perspective we don't want to be left behind. So we are introducing full desktop support by mid year. We're actively working on it. That's an area that is coming back. It's as simple as that.

So is there certain functionality within C Sharp that makes it difficult to automate certain things as people may struggle with maybe, I guess custom components would be one of them. But is there anything else that maybe you think could trip people up?

It's the complexity of code. I mean you've probably also heard there's not that many Java libraries, right? Because they're very similar in the format. So it's the complexity of the code, it's how you're developing your applications. And specifically if it's like a web forms based application, right? Or if maybe an MVC application. But if it's like a web forms based application, which it's an old technology but there's still many, many, many companies actively building their new systems on web forms, which is another discussion for another day then the framework does help with that.

Now you didn't mention in your experience a lot of BAs, business analysts or experts in the way an application works also contribute to automation. How is that done? Is that, do you have certain technology like low code or no code? Is it keyword driven?

Yeah, you know, we have low code. Being technical, the low code thing is an interesting aspect, right. So it's always up for debate with everybody. But we do have a low code solution, almost no code, which allows those non technical folks to be able to record, you know, work off their TCMs, the test case management system and you know, create the test out. But that's where at a certain point you always hit a limitation, whether it's something like a data driven test or. And that's where we can easily flip the code even directly on the same test. You can actually swap any step that you have in your in test studio over to code code whatever you want to and return back. So it allows that really simple flexibility. And because we have a Visual Studio plugin as well, the developer doesn't actually need to leave Visual Studio in order to make those changes, those technical changes that are required, does it make sense?

Yeah, absolutely. So I guess that brings me to my next question. The name of this episode is Planning, Design and Development. So since already in the Visual Studio ide, is there anything that helps people plan? Like here are the common tasks you need to do, or someone just submitted this and it alerts other people. How does the planning piece work?

Yeah, the planning piece for us is we do have full support for tfs. So most of our teams are using some version of tfs. Whether it's old school on Prem or somewhere in the ether, it's somewhere the support for that. So they have a great test case management tool. So again, why go and try to compete against them when this is the ecosystem that they're using and you know, they're already paying for part of their subscription license? We can work with that. We also can submit bugs into jira. So we can work with jira. You know, JIRA is an amazing system. It's a bug tracking system, but it's used as anything and everything. Right. It's got a very unique place in the ecosystem. So from the planning perspective, we can support that. We can also take in manual test cases. So if you have you had a spreadsheet, you can actually import that into Test Studio as well, which is a really nice feature. When you begin to plan and then when you start to stub out your test or set up your project, as I mentioned earlier, it's all file system based, so it sounds a bit old school, but for testing it works really well because again, you can put that right into your TFS or git or whatever you're using. And then at the same time you can see that file structure in Test Studio. So if you need to replace a file, it's really easy to actually see that visual tree. And then beyond that, we also have an elements repository which is not unique to us. A lot of the products have it. But what I love about ours is that if you change it, let's say that while you're developing, you change something. It's happened many times, right? And they change the look of the button or the color of the button or whatever, you can just update that element and it propagates to all the tests. So again, you can set all that stuff up in advance before you get really into the. Into the regression building, if that's the direction you're heading.

Nice. So once you have the planning in place, what's the design piece that comes in? Do you have a Certain framework that you use to like developers start, or is there something that's built into your solution that helps people design code in a certain way?

Yeah, I mean, so our framework will help guide you, it provides you all the steps and it kind of walks you through the process of designing those tests as well. From our perspective, if you're non technical in using just the no code, a low code examples, our tool is actually going through and providing you guidance as you actually build tests. So for example, if you go through and create like 50 steps and don't even bother checking, right, what actually happening is testudio will stop and say, hey, you may want to add a verification here. Hey, you may want to do this. And we notice that you actually entered a password. You want that password to be encrypted or hidden. I shouldn't say encrypted, hidden. So it does from the design perspective help so that when the developers who are really following more of a design principle get it, they're not dealing with again, a 50 step test. That's like just plowing through with. We have this feature which I hate, but our customers love, which is continue on failure. A lot of tools have it, but it's like, man, this one gets me. We've had people like, oh, we want to turn it on, like can we make that on by default? It's like, you do understand that that's not what it's designed for, but either.

Way, so yeah, I see that as a feature and sometimes, you know, yeah, I could see it being abused for sure. So is there anything else you see that may be abused in automation besides that may be kind of like a workaround that people.

Yeah, you know, it's a great question, right? When you look at, I was having a discussion earlier with someone about the testing pyramid, right? And it's like, are we building the right system? Are we building the system? Right? We've all heard this, right? And it's funny because, for example, and I'll use web forms because I already started earlier today. I think that's going to be the flavor of the conversation today. So there's a lot of AJAX responses, right? So a lot of times what people will try to abuse is, you know, they'll try to set up their tests but are not thinking or they're not looking at the test case correctly to ensure that they need to simulate real typing, which our tool does. Because in Ajax that's important, right? So like if you want to make those, those web forms calls, you want to make sure that you you start typing and then it just like calls back to the server and pulls the data. If you're doing something like lazy loading or something like that, so. Or if you scrolling through with lazy loading. So like sometimes you want simulate real click, sometimes you want to simulate real mouse, sometimes you don't need. We see a lot of abuse when people just shut that off because it just allows them to drop text and plow through. And then they say, you know, my test case broken. It's like well. Or I got an incorrect reading. It's like, well, you know, you need to kind of follow what your application's requirements are. You know, sometimes it's simulate real quick, sometimes it's ensuring you're looking at the screen. You know, it's maximized versus minimized. Right. You have to look at that environment set up nice.

So I'm also thinking back to. Because this is seems like it's baked into Visual Studio developers. Are they doing test driven development with this? Like how do they know when to run automation? Is it baked into the CI cd when they run a test, do the test automatically run? Or like how does it work within the developers kind of flow?

Yeah, so with the developer's flow, obviously we have support for CI cd. So whatever tool out there we can support in their flow, I mean they know when to run the test. I suppose when they feel that that test case is complete or that test scenario is lined up and from there it's a matter of it or whoever would configure just configuring that CI CD so that when we run the test it just runs that post build script and test Studio goes off to the races. What I like about our product is the fact that they don't actually have to run their tests on their machines. They can actually deploy it out to a farm. So they could be using our test runners to execute that wherever. Right. So that's good. So in their workflow it doesn't stop them and they don't have to just stare at their computer while the machine's going through typing and doing all those things.

For some reason this keeps popping in my head. Fiddler, Fiddler. Whenever I think of Telerik, I think of Fiddler. Is Fiddler baked into the solution at all? Is that a completely different product? Does that fall into the life cycle at all?

Yeah, so Fiddler is a completely different product, a very popular product. I mean I think it's probably one of the best known products, you know, in all of specifically for web developers on Windows. But on Test Studio what we can do is I'm sure you're familiar with the Fiddler Stack Trace, right. So you can record that stack trace and you can actually import that into Test Studio. So where this becomes really, really cool is when you're running load scenarios. Right. So if all of a sudden you start getting these weird 500s or these weird errors on your server, you can actually take that, that stack trace that you got import in Test Studio and throw, you know, a couple hundred users at it and see what happens. And that's easy. It saves a lot of time having to recreate, you know, those test runs. So that's one integration point that we have with Fiddler which is very useful. You know, outload is, it's a huge value add for our customers. It's not expensive like other load load solutions. And it's designed again to be a tool that, you know, assist the QAs and also assist the developers in testing some of those scenarios. Because typically, for the most part, load is handled in another shop, another part of the business. Right. That's maybe at this point it's, you know, let's call it DevOps. Right. But it's handled on that side of the house, at least for our customers. They can actually run load scenarios. And if they do detect that there's something, for example, they imported that Fiddler tracing. Yeah. In fact, we are getting all these weird readings from the web servers. Then at that point they can go ahead and submit that ticket, if you will, over to the folks that are actually going to run a more, you know, a deeper load test to figure out what's actually happened. But they don't have to wait. And that's, that's the, that's the beauty. And that's why our customers love our load engineers.

Oh, that's really cool. What I love about that is, you know, we're trying to shift things earlier and earlier in the software development life cycle, shift left. And performance is one of those things. And this is a great way where when people think of a performance, they just think of like a full blown stress test. But this sounds like a great way to get your developers involved earlier, have performance baked into the application before you actually went to that stress testing kind of phase.

Yeah. You know, a lot of times, like I mentioned, they love it because they don't have to. Sometimes it can wait a few days to get those test results back from the, from those folks on that side of the house. So.

Right, right.

It at least gets them to understand, okay, well, we do have a problem. We can go do something else. Right. While we wait for these results to come back.

So I know another breaking point, usually within the software development life cycle is management getting the information they need at the right time. So it seems like you have QA people, testers, developers, you have bas involved in this. You're doing some performance tests thrown in. Like how do managers know where a project stands?

Yeah, that's a great question. So part of our product is a management dashboard, right? So it's a fantastic tool, web based, so it doesn't require, you know, the management to do much, but it's giving them a live view of what's actually happening. So they're seeing successful test pass, you know, errors that may be occurring as well. We can generate email reports so after every test run we can go ahead and send you an email, which at a certain point, you know, we all used to get those visual studio emails, like they start to become very quickly a rule and very quickly put somewhere else. But this dashboard, it allows us to, to again showcase that information, showcase what's happening, what success rates, what tests have passed. And it's all included in the licensing. So they don't have to buy separate licensing, they don't, you know, it's again, a lot of value add, just like our load for the management. And it's simple, it's not full blown test studio. They're not opening, seeing an IDE and seeing an engineering tool. It's a dashboard, right. It's a very simple dashboard that gives them the information that they need in real time.

Perfect. And you know, I know you talked about low code a few times already, being a former developer. Well, it's still a developer at heart or probably still developing. What are your thoughts on low code? No code. Because a lot of people here, they're very skeptical. Is it really something that's used by your customers from these banks that you talked about in education? Do they actually utilize this and are they successful and if not, you know what's causing them to stumble?

Yeah, they're very successful. Again, without saying, we have a large prestigious university in Cambridge, Mass, who uses our tool and none of the folks who are using it are actual QAs. They're all a mixture of folks, managers, BAS, and they're using zero code. They wouldn't know what to do with code because that's just not their area of expertise. And they're very successful testing their solutions with the product. They've done internal case studies, obviously we can't release them, but they've done internal case studies with us about the success they've had with it. But we've also had other other organizations use the no code very successfully. So it is possible to do. And I, as a developer, I'm always skeptical about it all low code solutions. There's been a million different platforms for developing low no code for mobile devices and we're still writing native, right? So but that's changing. That's actually is now finally changing correctly. So it is possible. But it starts with good test case management, starts with good understanding of your solution, what you're actually testing. So as I mentioned earlier, that's why Test Studio has these features where it's like, you know, there's an error, it's going through and looking at what the error is and providing you some tips or some guidance on what you should have done correctly. For example, if it notices that you're clicking through all these different cells and grabbing data and placing it into somewhere else, it's like, hey, maybe you want to do a data driven test, it'll be more robust. On top of that, our low code solution, as I mentioned earlier, we have that Elements repository and when I make a change to that repository because the application changed, I moved the button from the top to the bottom, right? It can update all my tests that are working with it. So that's a really cool part of our product. Especially if you're not technical. When that change is made, it'll just automatically propagate to all the tests that are using that particular element. And then finally, the other thing is when we're executing a test and recording it, we're taking pictures of it every single time we're comparison, we're getting all this sort of information right? So if something doesn't line up and we're doing no code, let's say we can physically take a look at what the expected result was and what it actually was at the time of failure. Non technical folks can still make the determination there's something wrong here. And if at that point they need to get a developer involved because they notice something that's incorrect, they can just take that and submit that as a bug right into tfs. The developer now has a picture. That old saying, a picture's worth a thousand words versus the QA trying to walk them through, they actually can actually see what's actually happening. And that, you know, at that point there's been zero code and they've actually submitted a bug into the system. Test Studio will grab all the information that it needs. Even the DOM at the time of failure and send that over to the developer, to the folks that actually understand what's happening behind the scenes. Right behind that black or in the black box, if you will. Kind of a long winded answer.

No, that was a great answer. So it seems like it is a real thing. It is being used successfully and I love the different features that you have to alert developers. So how does that work? When someone's creating something, they're doing something wrong. Does it bubble up and like, hey, you may want to try this. Like, how do they know if they're doing something wrong? You said it. It says something about them. Maybe do a data.

Yeah, we. Yeah, exactly. So we provide guidance on failure. So if we looked at. I'll give you an example. Let's navigate to telerik.com, let's log into the account using the email address and password and hit submit. And then it doesn't log in. Let's say it errors out, right? So it may look at the test and say, okay, it looks like you failed because the expected result was the homepage, but it wasn't. So you may want to go ahead and add a verification step to make sure you're on the right page before you hit submit. Because I mean, from the tools perspective, it knows it's entering information to a text field, it knows it's looking for that login submit button. It's clicking on that button and executing. Right. And so now you have two scenarios, right? If you were recording the test and you made a mistake and you actually ended up at a different page, it's going to error out, right? Because it just jumped to the incorrect page. Lots of times you get redirected for many reasons, whether your licensing is expiring or there's a promotional. Right. So it'll say, hey, you may want to add a verification step to make sure that as you're going through, we'll take a pause, poke our head up and see what's actually happening. Right? Are we at the right step? So the tool will do that. As I mentioned earlier, again, a good example is if it notice you're clicking through a bunch of data, may say, hey, why don't you do a data driven test? You can attach directly to a database or attach directly to an Excel sheet or a CSV file to import that data. So it's going through. And we didn't want to use the term AI because I think it's a bit overused for a lot of tools because there's no true algorithm that's learning itself. It just knows the complex scenarios that are going through. It knows that when a user makes a mistake here, it's got to be one of a few things that are actually happening.

So yeah, that's my next question. Thoughts on AI machine learning? Because unlike other solutions out there, let's say I don't see it posted all over your website. So it seems like you have that type of functionality. It's just not being promoted right now as AI machine learning.

It's not? No. We actually have a patent pending for it. If we're going to make the claim that we're AI, we really want to have a learning algorithm there that's actually doing as simple as that. We don't want to make claims of things that we're not. We don't test Java applications unless it's web version of it. But we don't want to be something that we're not as simple as that. We want to stay true to what we are and do good with what we do. And our customers love us for that.

No, I love that because I run an online event every year called Automation Guild and there's always people that deal with C Sharp that always like or Windows applications that kind of left in the cold. So it sounds like who's this solution for? I don't know. I know you said it a few times. I just want to make sure people, if they're listening, like wow, this is exactly my environment or my ecosystem, this is going to work for me. Or people that are like this doesn't work for me, I get some value. But it's not going to work for my developers and my team.

If you are a C developer, right, and if you're developing WPF applications or if you're developing still working on web forms applications, a lot of the banking industry still has web forms applications or if you're doing blazor, if you're heading in that direction, right. This is a great product for you, a fantastic framework for you as well. It's a very robust, very complete framework. And on top of that, the framework's free. Go try it out, there's no charge for it, we'd support it. So if you're working again within Visual Studio, again a great product for you. If you're a quality assurance engineer and you're in the process of moving into automation and as you know, I mean automation is not something you can snap your fingers and it happens, you're looking at a two year journey at best. If you really want to want that full, you know, Spectrum. This is a great product as you're moving into automation because it's going to take some of the basics of testing and make complex scenarios. I mean, building a sustainable regression is not easy. It's. They take a while. Right. But what it's going to help you with, it's going to help you with taking, you know, the thousands of test cases you may have and moving them into a product that's compartmentalized. So it allows you to, to handle your tests accordingly and then scale. Right. As you continue to build them, build them straight out. You also have that collaboration with the developers. So that ecosystem works good. One of our sales guys always says, you know, he has his like everyone has a seat at the table thing and I agree with it. I mean, everyone does have a seat at the table when it comes to our product.

So one thing I forgot to ask is when we talk about C Sharp and web automation, not desktop automation, which is something that's definitely needed. Desktop automation that I hear from other testers anyway, is this use sliding behind the scenes? What technology is he using?

Our product is using our own framework. Yeah. It's our own in house framework. Or essentially through an acquisition of that Ardataz company.

Gotcha. Cool. So you know, you didn't mention something. Usually if someone's signing up for automation, it's like a two year journey. A lot of people are like, I'll just use a free tool like Selenium. It's like, well, Selenium is not a tool, it's an API. You're going to need to learn how to use C Sharp. You're going to have to install it.

Webdriver.

It's not an easy ride. So yeah, with the webdriver and everything. So this sounds like, like you said, this would be a great solution for those folks as well.

Yeah, it's a great solution. You know, Selenium has a place, it's a great product. But again that it's just, it requires a lot. It's not as easy as, you know, it's made out to be.

100%. Right. Right. Cool. Okay, Romero, before we go, is there one piece of actionable advice you can give to someone to help them with their C Automation testing efforts? And what's the best way to find or contact you or learn more about Test Studio?

Yeah, so working backwards in that, you can Definitely go to telerict.com test studio. You can go ahead and everything's there. You can go ahead, pick up a trial documentation. You know, one thing is Telerik progress is known for is the documentation. We have great, great documentation. So it's an easy way to get going. And if you want to contact me, you can find me at Twitter. Ramiro Milan, you can find me on LinkedIn. You can shoot me an email if you want to. I'm always love to have conversations or maybe you'll see us around at the different conferences. Hopefully when we can get back to this, you know, this scheme. I'm always at the conference talking to people, talking to our customers, always. But talking to the customers that we don't have to understand what their needs are in the advice. The best advice that I ever got is that every journey has a beginning, right? Every journey has a beginning. And like when it comes to automation, don't be too hard on yourself if you run into these, like into these errors or problems or scalability is. It takes time. As I said, two years. It's. It's a long time in the scheme of things. It's not, but it is. So I mean every journey has a beginning. And hopefully like with a product like ours or any other products that assist out there, those can assist in that journey as you get through whatever the outcome may be, whether it's a full CICD pipeline or whether it's a full regression or something as simple as automating some of the functionality to save you. Sometimes you can get home a little bit early for dinner. That's simple as that.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a.

And while you're there, make sure to click on the Try for free today link under the exclusive sponsor section to learn all about Sauce Labs awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? 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.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.