[Webinar Live] Why Autonomous Testing is Essential?

Okay, so what are the challenges with testing automation? So first there are two basically. It's test creation and test maintenance. So first of all, it is exceptionally hard to create tests, automated tests, tests. It usually, on average, takes an automation engineer a year to produce about 50 tests. And then you have to also create and maintain those tests. And again, only engineers can maintain those tests. On top of it, it's also a bundle of tests and engineers, because if your tests fail, then only engineers would be able to tell if its failure is legit issue, or if it's their own issue, or if it's a random flakiness. On average, for example, all Selenium tests we'd always fail and anywhere between three to 8% of all Selenium tests will fail if your test suite is larger than 100 tests.

And then it's continuous engineering time to understand what's going on. Now, let's say you have certain amount of tests, your engineers then start to spend more time maintaining those tests instead of being more productive and creating those tests or doing anything more meaningful. It's literally a law of diminishing returns in here. You keep basically spending time, more and more time, maintaining tests as soon as you have more and more tests. So this is where times goes. On top of it, in a lot of cases, it's also a catch up game whereas as product moves forward, you will get maintenance tickets for your tests. They will start to fail or... And key engineers would need to update those.

On that, I would like to start from a help with test creation. And this is where autonomous testing come in. So what do we call autonomous testing? Autonomous testings are two things for us. Number one is autonomous test generation. And this is what I will be talking about on this page, as well as some rules and AI, to help with test maintenance as well. Let's start from test generation. And there are two ways how anyone could produce a test autonomously. So first is based on crawler, or set of rules, where the system would go through your application and we'll be able to figure out some functionality and build tests. So that works very well in two specific cases. Now first, in case of mobile, because there is a very limited amount of functionality available on every mobile screen, so for the system, it's pretty much easier to figure out what needs to be done compared to web applications. And another example would be static websites where system cannot automatically detect new pages and go through the pages, at least making sure that there are no broken links and the structure is not damaged.

Second one is based on analytics that you could install a library similar to Google analytics, but you then can use that information to produce tests. You can literally figure out what are most frequently used and [inaudible 00:14:16] scenarios, and then build tests automatically out of the box to cover most frequently used scenarios. And that usually works very well. We have websites which have a lot of traffic. So there is a lot of information to get information about what's most frequently used or, given enough time, you will accumulate that information. It does help to go through more interesting and meaningful scenarios. However, it has another challenge that, unlike crawler-based discovery, which came out of the books, go through your test environment. Whatever behavior of your end users, you record it on one environment, being it production, for example. Might require some attention in order to be able to run it on another environment, be it your test or staging environment. Where inevitably some differences in structure of your pages and definitely generated test data might not necessarily work out of the box to go through the same flows. So you might need to update the data.

And finally products do change. And especially if your product is live, it's probably changing all the time. So it's inevitable. There will be legit reasons for those tests to fail because of product changes instead of bugs. And for that, there should be an easy way to maintain those tests. If you generated huge amount of copy paste and your product changed, then clearly it would be a huge challenge to fix those and it wouldn't make sense to maintain those tests. There will be basically a waste. So overall, summarizing, in order for autonomous testing to work, tests should be meaningful, readable, stable, and exceptionally easy to maintain

Okay. So going to do a last call and also remind our attendees that to request a three month unlimited trial, you can go to testRigor, T-E-S-T-R-I-G-O-R, .com/request-trial and submit the form to contact us. Our team will be in contact with you, and please specify that you are one of the attendees for today's webinar, and we will be with you and help you along the way. So with that, thank you all again for joining the webinar. We really appreciate you being with us and the questions that you asked