Self-healing Execution Cloud: Preventing Failures and Saving Time with Adam Carmi

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 have with us once again Adam Carmi. He is the creator and founder of applitools. So today you want to learn all about a revolutionary new way to run your test faster and more reliably in a self healing type cloud using your existing open source test. If you don't know, Adam is the CO founder and CTO at Applitools. He's also the inventor of visual testing, bringing over 20 years of experience from a bunch of different leadership initiatives and experience from applitools. And prior to finding of founding applitools, he held management positions at companies I think like IBM, Microsoft and Intel and a bunch of other ones. Really excited to have him back on the show. You want to miss it, check it out.

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 over to testguild.info and let's talk.

Hey Adam, welcome back to the Guild.

Hey Joe, it's great to be back. Always fun to chat.

Yeah, absolutely. It's been years. I don't know if you know how long. I think last time you were on episode 43 in 2015. So it's been like, wow, eight years. Yeah, it's been crazy.

Time flies.

Yeah.

You haven't changed at all.

More white and grays for sure. You look the same. How nice.

Thank you.

Yeah, so you know, last time you were on the show you introduced I think was the first time new technology called visual testing. And today I think you're going to introduce something that I think is also the first of its kind, something called the self healing cloud. But before we get into it, for people that may have missed that episode back in 2015, what is Applitools?

Yeah, so Applitools provide a test automation platform that you know, today is used by hundreds of the world's leading companies. What's special about applitools is basically two technologies that we've developed, disruptive technologies that are unique to us. The first of them is visual AI, which is basically a large collection of computer vision algorithms that mimic the human vision with very high accuracy. And it allowed us to take a very unique approach to test automation. Basically inventing visual testing, but actually proposing a new way of implementing your end to end test component testing, anything that has to do with testing through the client, anything that has a UI which eventually allows you to drastically increase your test coverage while reducing the amount of test code that you need to write by 80% and requiring a fraction of the maintenance effort that you would normally require to maintain your automated test suites. And also opening it up for everyone in the team to work on. So you can have any manual tester, business analyst, every member of the team that doesn't have developer skills, he can take complete and full membership and ownership on maintaining the automated test. So that's the revolution around visual AI. The second invention is the ultrafast grid that came around, we came out around 2018, which is basically the best way to test cross devices and browsers. So it allows you to execute your visual AI based test across different devices and browsers to get that coverage in orders of magnitude faster and more reliably and more securely than you can with any other device. So this is the big like two technologies that we've had and the execution cloud, the self healing execution cloud that you mentioned is our latest and huge addition, recent edition.

Absolutely. So I want to dive into that, but I'm already off topic. I just want to say, you know, since I learned about Applitools in 2015, I bring this up as an example of how I see AI progressing in the future. So I just want to get your input on this. So with applitools, what it does, it bubbles up insight and requires a person to say, is this correct? There was a change, but it requires a person to look at whatever the AI algorithm has bubbled up as an issue that someone needs to go in and say yes or no. I see that as where we go in the future with AI, where other vendors are going towards. Do you think that's the correct implementation of AI solutions rather than just relying on the algorithm to do it? It's going to require a human being, as always, to make sure it's valid, whatever it's prompting you for.

Yeah. So I think that at the end of the day, I think that first of all, we see people every day arguing about what is right and wrong? I mean, I see it between my engineers and engineers and the product team. One guy likes it, the other one doesn't like it. One guy thinks it did great, the other doesn't. Who says that the machine can really decide here? That's my first question. So even if we could implement it, which we can, but who says that the machine can decide? The second thing is I think that today, if you, especially if you want to sell a product that people will buy, people are very, very wary of allowing some obscure AI to make decisions when it comes to testing. People want certainty. They want to know what is the coverage that they're getting, what are the risks that they're taking. Okay? And if you want to talk about the future, when I look on at ChatGPT and large language models and generative AI and all this stuff that came into our life in the past months and people are all of a sudden afraid how it's going to change the world so not to get into of where it really is and where the hype is today, which is a completely different thing. And we need to give it time and see how it will evolve and in which areas it will really have a big impact and where it won't have any impact. Let's assume the worst. Let's assume that AI will start building applications for us. This would be the best thing that would ever happen to the testing world. I mean, the better this thing is, the less qualified the engineers will be, the less ability to understand what is being built, how it is being built. Today, when you add a new feature, you have a developer that knows what he's doing. He's a software engineer, he knows what he changed. He can come back to you and say, I changed this, it's safe. This is the impact, this is what you need to cover in your test. Imagine working with the tool that when you ask him the same question twice, he gives you a different answer. And the guy that is using it is not a good engineer. So he cannot really understand what happened or influence it. Right? So the world of testing is going to be much more important. And the need for testing tool won't be reliant on another AI to tell you if the other AI did well, it would be a true regression based test. You would like to know, okay, I know how it worked before. I want to know everything that changed from how it used to behave before because you won't count on the guys that's changing it. Okay? So I think that the future is very bright for us. Testers and us working in the testing community. And to go back to your initial question, I think people want to be involved. I think they don't want to do repetitive, boring, mindless work. They want to use their intellect and understanding of the customer, the expected user experience, the knowledge of the product and what they intended to happen and be able in the most efficient way to make sure that it works that way. And the most efficient way is for them to just look at changes and say, yes, this is okay or no, this is a bug.

I love it. Great insight. And you mentioned a lot of people are afraid that's going to replace. Well, you kind of implies a lot of people think that AI is going to replace testers. But once again, I always go to Appli Tools and said, now, I used to work for a company that used to compare X rays to one another and it was very difficult to do manually until we brought applitools in and was able to spot differences that I don't think anyone could do manually. So I asked how many testers do people think that replaced? It was zero. So it's the same exact thing I see in the future. So absolutely.

Look, at the end of the day, this is a productivity tool, but you still need the skills to evaluate what you get and ask for corrections. And, you know, you still need those skills. And you know, when the spreadsheet was invented, you know, people thought that accountants, bookkeepers won't have a job anymore. The exact opposite happens. So maybe there will be many more jobs open because more people would be able to apply to them, but the skills would still be required. This is how I see it at least.

Very nice. All right, so besides applitools, Eyes, which does the visual validation piece, you mentioned the ultra fast grid, but with the latest technology, it's the execution cloud. So all these built on one another, are they layers on top of each other? Are they all different products that don't relate to one another?

So they all different products? Let's talk about the execution cloud. Execution cloud is completely independent of the other products, so you can use it today. I mean, if you need to run your test at scale, okay, you definitely don't want to build it by yourself to produce this scale for a variety of reasons that I can expand on. But if you need to run it at scale, you can just run your tests on the execution cloud, regardless if they're using EYES for visual validation or not. So even if you have just Selenium webdriver IO test that just have plain traditional assertions in them, not depending on any other eyes product. You can use them to be our infrastructure to execute them and scan with a lot of upsides to it. So it would be the fastest solution by far, it would be the cheapest solution by far. And you get self healing out of the box without changing a single line of code in your test, which is super awesome.

Yeah, let's dive into a little bit more than I think the better question I should have asked is what is the execution cloud? At a high level it seems like it's something that you can use your existing test or open source test with and you just run it in the cloud and it automatically is able to then self heal itself if it can't find an element or a visual identification. Is that, am I understanding that correctly?

Yeah. So it has nothing to do with visual or with eyes or validation. What it does is basically itself heals your test, your open source test by itself. And let's talk about, if you want, I can elaborate on what self healing for the people in the audience. That not so.

Yes, that'd be great.

What it is. So when we, if we look at any of our tests, each step of the test interacts with some element in the ui, either finding an element in order to click it or type into, in type some text into it, provide some inputs, or we find that just to go over, query the properties and assert on the right. It happens on every test, either interaction step or validation step. Now, in the UI of the current page of the application, there are hundreds if not thousands of elements. So we need a way to find the elements that we want to interact with. And in order to do that we need to execute some queries, queries that basically find the elements for us. And we call these queries element locators. Right. I can look for for example, a link under an element that has an attribute, an ID attribute with a certain value. Now the problem happened and this is how tests are built. The problem is that if the UI changes because we are adding a feature, or some developer decides to refactory because he thinks it could be built in a better way, the structure of the UI changes and that can cause some of the queries in our test code to fail. It's still the same query, but it fails to find the element that we're looking for and this causes our test to crash. Okay, the dreaded no such element exception in our test. So the worst thing about this, that these failures always happen at the worst possible time. Right? You're just about to release and you want to run the test and release fast. Or a developer is now pushing a code change and he wants to see the results and move on to his next task. And all of a sudden, boom, dozens of tests fail. And there's absolutely no choice. You have to stop whatever you had planned to do that on that time. You have to put it aside and start going over the test results and figuring out what went wrong and going into the test and fix them and rerun the thing, hoping that this time it will pass and it can waste hours, right, just in that work. And it's the worst point in time where you want to do it. So basically what self Healing does is that when you are trying to find an element and the element locator no longer works, self Healing is still able to find that element on the page for you and allow your test to continue passing. This is the bottom line. It means that even when the UI changed, your test will continue to pass and you can then later on, when it's convenient to you to go and update the test and correct them. Although, because self filling is so robust, at least ours is, and we can continue and find the element for you forever, even if the UI continues to change again and again and again, you never have to go back and fix your test. So basically it's enough for you to find the have a single run of the test owner infrastructure to find your element once. And this allows us to be able to continue and find it again and again and again, no matter the fact that the locator is no longer relevant to how the page is implemented. Okay, just to give an analogy, just like when the test fails, you as a human being is capable of looking at the ui, finding that element. Oh, here it is. Let's look at its attributes and fix the test so we can find it again. This is exactly what self healing does. So the test gets corrected and you don't need to do it yourself. Okay, the test code remains the same, but on our infrastructure we are still able to find. I can go deeper into how that works if it's interesting, but that's the bottom line of the value. And again, because that when that happens, okay, it means that your entire test suites become much more stable, your builds become much more stable. You save hours in looking at failed test results and analyzing them, and hours in going into test code and fixing it again and again and again after each UI change. So the impact on the stability and maintainability is immense. And this impacts your ability to succeed with your test automation project. Because you have more time to continue and keep up with coverage. And you will spend less time rerunning tests and dealing with flakiness and breaking tests and more time to enjoy getting that coverage as soon as possible.

I think people could definitely know the value of hearing this, but, you know, I guess the question is, you said you can dive into how it works. I know there's two ways. I know some vendors work already. They either use an image to find the location based on a baseline image of something to know where an element is most likely located. And the other one is it'll use like backup methods, like it'll have a history of, here's the XPath, here's the CSS, here's the index. So it'll fail over to all those, the ones it has in its memory from the past runs. So if the first preferred way fails, it'll fill down to the other ones. Is this the same thing or is this different?

So we've developed new algorithms for that. By the way, we did the second approach back when we were maintaining Selenium ide. We built in the alternative locators method with fallback, which was a very naive approach to it. We've actually built a new AI engine to deal with self healing in the execution cloud. It works amazingly well. Very difficult to. Even if you try very hard to make it fail, it doesn't fail. And we actually compared it with everything else that's out there and it's much better. But you know, everyone needs to try from themselves and reach that conclusion. But here's how it works. Basically every time we find an element, if you're using a certain locator to find an element, every time we find it, we capture hundreds of data points about that element, all its attributes, the location in the hierarchy, details about its ancestors and neighbor elements, basically everything that you can think of, including an image of that element. We store all that data in the database using the locator that you use to find the element as key. And every time the test runs and we rediscover the element, we learn everything about it from scratch. Okay, so it's up to date with the changes in the element. So even if the element is still locatable, using your locator, it might change in various ways. We keep track of all those changes all the time. Now let's say the UI changed and now you're using the same locator that is now broken to find the element. So we try to find the element with your locator. We fail to do It. Okay. Now, instead of just returning an error, which would fail your test, which is the usual thing that would happen, we actually take the locator, go to the database and extract this wealth of information about everything we know about that element. Now, we are running our own proprietary algorithms to use all that data to be able to locate that element. And we have a huge amount of data, okay? So we search for it using our algorithms and our methods, using all the data that we have on that element. And if we manage to find it, we relearn everything about it, store it in the database under the same broken locator. Okay. The same locator that no longer works, we update that entry. We indicate in our dashboard an alternative locator, strong locator that you could use to go ahead and update your test if you want to. We indicated there was a self healing event, so you can go back and track all these events if you want to and fix your test, and then we just return the element that we found to your test. So as far as your test is concerned, nothing happened. You looked for an element, you found it. Because we learned everything from scratch about that element. Next time we run, you can still use the broken locator. We know exactly how that element looks and will for sure find it. And after, if it changes again, every time we find it, we keep learning everything about it. So basically we can postpone the point of you having to fix a broken test indefinitely. Okay, that's the idea. Now you can keep using your broken locator for at this point in time, it is a locator that is simply a string and applitools locator, for that matter, that is used to find your elements, and it doesn't need to have anything to do with how the UI is implemented anymore. If you prefer, we can go ahead and use the information in our dashboard and copy the new selector that we propose and paste it in your code and fix it that way if you want. And then it will go back to relying on your locators and actually find the elements that way. But you don't have to do it.

All right, so someone listens to this, might say, well, that sounds like it has some sort of overhead on it at times. But you said it's faster when it runs on the cloud, so how do you compensate? It seems like it's doing a lot. There has to be some sort of layer that's doing some extra seconds, adding to the execution.

Yeah, it adds a few milliseconds for finding an element in case you know, self filling needs to kick in and find it. But I mean, you know, we, I don't want to say specific vendors, name specific vendors, but you know, I did a webinar a week ago and I showed live how it actually runs twice as fast as a leading lab provider without naming names. Twice as fast. I mean, so on one hand and this guy, this other vendor does not have the self filling layer and it's still twice as fast. And when it's twice as fast, we are talking about saving many, many seconds per test, right? It could be 10, 20, 50 seconds a minute, depending how long the test is. So adding a second of overhead and reducing half a minute of overhead is definitely worth. But in general, if you take the amount of time that's saved in rerunning the tests again and again and again, going into the test code and fixing it, and spending the time looking at the logs and investigating the problems. So for sure you save a huge amount of time. Not just execution time, but work time, you know, productivity time, mental health time.

Yeah, you beat me to the follow up. Because that's exactly. A lot of times when people think of time, they just think of execution. But most of the time is usually spent on maintenance. Like, oh my gosh, I have 900 tests and it could just be to an element changing and it takes you hours and the next build is out and running. This will save you from all that. Of course.

Yeah.

And it sounds like what I love about this as well is just like you've always done it, someone will always say, well, how do I know it's not hiding a real issue? Well, it's not trying to hide anything. It will tell you we did this. Here's what it was and here it is now too. So people can dive in more.

Yeah, that's for sure. But also a lot of people, I mean, don't look at things, I mean, okay, so what was the issue? An implementation detail in your page changed. That's not an issue. If it was important for you that a certain element would have a certain attribute and that attribute shouldn't change, you should have asserted on that that would be the correct way to do it. You would like to see the test fail. Telling you, I expected this attribute and it was that value, not what I expected. It should be as an assertion. It shouldn't be, oh my God, no such element exception. Something crashed and figuring out, you know, what happened. So it shouldn't fail as part if something should be validated. If your test is trying to prove that is as expected, there should be an assertion there. Interaction code is not an assertion. Okay, if you try to click something and the page implementation change, you still want to click it. This is what's supposed to happen so you can get to the validation part of the test and not lose coverage.

All right, so some other questions that are popping. I know people are probably thinking, oh, if I this sounds great, but how hard is it to implement? And two, will I be locked into the solution forever and ever if I start using it? So the first one is how hard is it to get started using it?

So it's not hard at all. You just need to take your existing tests. If you have for example, a Selenium and you're using like a webdriver instance or remote webdriver to run it either locally or in house on a third party lab provider, you just need to use the same remote web browser and point it at the applitool's infrastructure, which is super easy. Just a small change in your test framework and you don't even need to change any lines of code in your test. So it's very, very, very easy to get started with. And what was the other the second question? Oh, locked in. So, and again, the beautiful. I think the most exciting thing about the self healing execution cloud is that self feeling. Regardless if the level of self healing that you provide is slightly better or much better or slightly inferior to what other vendors are providing. I think that the main thing here is that self filling, which is not a new thing. We didn't invent the concept. It has been around for a few years, but up until today, vendors used it as a premium feature to lure customers into their closed platform. And this was a way to lure you in and get you to make a decision to throw away all your existing investment in test automation that maybe you worked years to build and start building everything from scratch in their system. Okay, which means that you lost all the work that you've done and your existing investment. It means that you lost your freedom to choose what framework you want to work with. Now you're tied to that specific platform and you have to use the APIs and the tools that are provided to you by that vendor. But third, you're pretty much locked in because if you dislike this framework, there's a very big problem to leave it because you have to throw away everything and start from scratch again. Which, you know, a lot of teams are busy succeeding, helping their company succeed, and don't have time to wipe out everything and start building everything from scratch. So the beauty about the self healing execution cloud is that there is no vendor lock in. You have your existing tests, you own them, you choose whatever frameworks you want to use. All you need to do is just run the same test on our infrastructure. You get self healing without changing a lot of code. If you don't want to run with us anymore, simply, you know, just run elsewhere. It's as simple as that. So there is no vendor lock in in this case and you can still be free to do whatever you want. So this is I think the biggest, I think innovation here and the biggest impact that this has. This is the world's first self healing infrastructure for open source frameworks. Okay. And this is the main, the highlight.

Love it. So I'm just looking at my notes from your webinar. I'll have a link to it in the show. Notes for people that actually want to see this in action with the coding examples you did, but you went over why you can use your existing open source test really easily. It's lighting fast. You mentioned affordability, but I don't know if you mentioned a price or you can mention a price. But like is there a percentage of how much more affordable it is than another solution or what do you mean by affordable?

Yeah, so for example, one of the leading vendors, of course I can mention prices. Right. One of the leading vendors is offering a concurrency in his cloud for $1500. That's the list price. The execution cloud cost $800 current currency. Okay. So that's the difference. Okay. It's very, very, very affordable. Which means that you can really save a lot of money running on our infrastructure in addition to getting a superior product.

Nice. Also I have in my notes, it's a single platform for authoring and executing tests. What's the authoring piece here?

So authoring is using eyes, basically. Okay. You can use EYES to author your test, do the maintenance of your test, adding visual and function coverage with all the benefits that I mentioned in the beginning. And you can also now execute them on our infrastructure so you can get the whole thing with applicables a single platform.

So I always like to think about how someone listening can actually implement or where it makes sense because I assume it doesn't always apply apply to everywhere. So the self healing, where do you think if someone's listening, if they have this situation, then self healing will help them as opposed to it won't help them if they have this other situation. Don't know if that makes sense, but.

Yeah, yes it does. So basically it's helpful when the UI changes in a way that you know breaks your locators, if you have extremely disciplined teams where the developers are very, very conscious of testing, and each element has its own own stable id, and they do code reviews and never make mistakes or change them or forget to add them, then your tests are probably super stable and everyone's happy. So the impact won't be that big. But for the 100% of teams that where that doesn't happen, then it will help you stabilize your test suite, prevent failures, reduce the amount of time you spend reviewing test results and fixing your test following UI changes. Of course, the more your pages change frequently and more often, the more value it will give you. Okay, now it is also helpful in some other cases. For example, in some situations teams have people, test automation engineers that are less experienced and are not so good at choosing good locators. So in these cases what happens is they end up choosing a bad one, which causes the test to fail much more often or to fail sooner than it could have failed. So self healing locators resolve that problem because all it needs is for that bad locator to be able to find the element once. Once that happen, you have the power of self healing to find that element for you with all the data and the algorithms that I mentioned before. Another case where it's very useful is if your application has simply weak locators, which is opposite of what I started with. In many cases you have a development team that is just building the product, doesn't care about testing, there's another team that needs to deal with testing. No one thought about the stability. There are no strong locators and the team needs to deal with what it has. And it's very difficult to choose one locator that is good because there isn't one. So self healing is very, very useful in that case as well. And the last example is dealing with applications that have a dynamically generated UI or dynamic IDs. I mean, everyone who tried to automate Salesforce, for example, with its dynamic IDs with selenium, know that it's an impossible task. But with self filling it is possible and doable because it's enough to have a single run that is able to automate the ui. And from that moment on self filling takes care of it, even if the UI is regenerated and elements have dynamic affiliates. Okay, so these are the use cases.

Yeah, great point about Salesforce for sure. I know a lot of people struggle with that. So just random thought popped into my head as you Were mentioning the first use case of maybe an inexperienced tester choosing a poor selector. Can this almost be used as a training tool? Then over time they're like, I use this selector, but it's saying this selector would have been better. It's almost like training your engineers also over time. Maybe. I don't know.

Yeah, I mean, perhaps. I mean, we didn't build it as a training tool, but actually it's super easy to filter your test suite runs and the tests within them to find all the occurrences where self healing kicked in. And you will see there exactly the failed locator that you try to use and a recommended strong locator for that element. Okay, so which we actually offer as a way for you to just have an idea of how to update your test. But people can learn from it. I mean, if they see that there are failures and it can definitely lead them in the right direction if they see it often enough.

All right, one other thought I want to squeeze in here before we go is we talked a lot about Selenium Webdriver IO. I know based on the webinar, that's the answer to the question, but the people that missed the webinar, are you going to support. I know Playwright has been really, really growing in popularity and Cypress is. It was growing. I don't know if it's still growing. But anyway, are you going to be supporting these other technologies or are you going to stick just to the Selenium ecosystem?

For sure? No, we are going to support it. We decided to. Actually, you know that it's funny. First of all, Selenium is like a very, very common framework that although is not the latest and greatest, it is still an excellent framework and many, many, many teams are using it. And there are plenty of legacy projects that use rely on it and will continue to rely on it for many more years. However, we actually, you know that we're working on the autonomous product, which is a fully autonomous test framework that is going to come out later this year. And we actually built this infrastructure. So that's. We'll soon talk again, I guess.

Have to get you back. Yeah, okay.

Yeah. But we built this infrastructure to help us run the autonomous test. So it was. We've already been using it internally for two years now, the execution cloud. And then we decided that it's time to maybe turn it into a product of its own, on its own. But the reason it is based on Selenium wasn't because we started and said, hey, let's choose the new framework and build it for it. We just used the infrastructure that we had in place and how we are using it internally but so this is why it's today with Selenium and Selenium based frameworks. However, we are already working on adding support for Cypress and Playwright and very soon it will be available as well. And we have a long list of a long backlog of additional frameworks including Appium support, et cetera. So it all will come out in due time. But of course we are super excited about this offering and we get huge traction now and it is very well received and this only encourages us to invest more in this infrastructure.

Awesome. Okay Adam, before we go, is there one piece of actionable advice you can give to someone to help them with their automation testing efforts and what's the best way that people can get their hands on the self healing cloud?

Best advice for automation what I would say is that not necessarily from the practitioner point of view, but from the value from automation point of view. I would encourage you to do two things. First of all, make sure you run as frequently as possible and as fast as possible and get as much coverage as possible. Don't run before just once before release. Don't run nightly run on every build. This is what the best in class teams do. You need to get to a point where the build takes no longer than 15 minutes, which is just about the time that a developer would be willing to wait before moving on to his next task. If you can get the coverage, the feedback to a developer on the code changes that he just pushed before he's moving on to the next task, you will actually make a difference. He will actually fix the code that he just submitted before starting something new. It will save hours in switching between the new feature to the old feature and back to the new feature. You will actually have commits with less bugs and you will improve the velocity of the entire team, eventually ending up with the fact that you will have more features for your customers and help your business succeed. This is where you should strive. This is what the best in class teams do. And in order to get to this combination of very fast execution and a lot of coverage and still be able to maintain all of that, you should rely on the modern tools that are out there. Okay? Tools that rely on AI to take out a lot of the code, to take out a lot of the maintenance overhead, to drastically increase the coverage of the test. That will allow every member of the team to maintain the automated test, just like what applitools products do. Okay? So don't try to save money on open source. You can still use open source as these tools to boost them, but don't try to save that money. This will actually save you a lot of money and save your business a lot of money. So this is my advice now in order to get started with the Execution Cloud. Basically all you need to do is go to our website and find the entry on the banner on Execution Cloud and ask for access and someone will open up an account for you and you can just start running free. You can do a free trial and try it out so it's super easy.

Thanks again for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com a450 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.

Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 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 test guild.info and let's make it happen.