Turn your manual testers into automation experts! Request a DemoStart testRigor Free

TechWell Webinar | End to End Testing with testRigor

Data shows that only 30% of end-to-end tests are automated in 2022.

But why?

In this webinar, we will go through the challenges that companies face when they attempt to automate manual testing. We will discuss the reasons why automating more than 30% is not possible with legacy technologies such as Selenium for the majority of companies. Join us to learn how testRigor solves these challenges, including how to:

– Allow manual testers to build tests using plain English
– Build tests purely from the end-user’s perspective, without reliance on details of implementation
– Achieve maximum test coverage


hello and welcome to today’s web seminar end to end testing with ai sponsored by

testrigor and featuring artem golabev before our presentation begins please let me explain the console the panel on

the right has a feature to chat ask questions answer polls and download the slide deck for today if you minimize

this panel just click on the chat button to reopen it if you experience any technical issues

please send me sarah crocker private chat and i’ll be happy to help you there will be a q a session at the end

but feel free to enter your questions at any time throughout the presentation to optimize your bandwidth for the best

viewing experience please close any other applications you may have running in the background

this event is being recorded and will be made available to watch on demand once the recording is ready you’ll get an

email with instructions on how to access the presentation and with that i’d like to hand it over to artem

hello everyone uh it’s pleasure to see you all here today and today we’ll

be talking about anthony and testing vpi thank you thank well for hosting us

okay so why ai and why uh like this is specifically important

for end-to-end testing and what exactly are we talking about here so you when you’re talking about android

testing you can concern a lot of different things even and testing not just testing in general

it could be web mobile apis devices cars driving and this and that and 10 000

other different things here today we will specifically be talking about them web

and mobile uh and i will just briefly touch uh api

and by survivors looks like polls came out uh

in about 15 minutes you will get us the result and i’ll talk to that

as well so why uh why are we talking about this

in general and why do we need the eye in the first place in uh end-to-end testing

well uh as you very well know test automation had been around

since 1990s is not something new uh however

in 2022 70 of all tests are executed manually

still and the problem is it actually resulting in 1.7 trillion dollar in

losses due to bugs because people just can’t

retest all the functionality all the time uh think about it uh in 2022 the requirements

is such that companies oftentimes are released

on daily or almost daily basis even if they are

multi-billion dollar enterprises why

oftentimes it is just related to security even if a new feature is not ready to release yet

and the company is not really on a continuous delivery schedule

nevertheless from time to time security vulnerabilities in the libraries require

companies to release updates on regular cadence so therefore even though the uh

the longer the larger updates might come up on certain cadence or from time to time


the smaller ones oftentimes are released uh quickly and therefore

uh in order to be able to test them properly we all need to have uh test automation

now getting back to the question uh we have this shocking number of 70

percent menu why is it the case

well uh we also as i mentioned already have all that

well uh is because it’s not that simple as soon as you writing tests you need to

maintain those tests and this is where the the problem uh coming in it’s not not just the uh that

on its own but it’s usually in conjunction with uh

uh with the budget as you very well know your budget is uh

probably somewhere in between ten to twenty percent uh of engineering budget uh this is what

is allocated on va and uh because of the way uh

selenium mapping test works uh uh the way we have written

requires so much maintenance that uh it actually makes it

like almost impossible uh uh to achieve certain goals i’ll speak

to that in even more details in a second so basically uh uh since you are

[Music] since you are in the problem in the process of

uh having very little test automation it’s usually a menu and because it’s

manual it’s a lot of a lot of a lot longer release cycles and bugs in

production and even automation itself

is not perfect not only it almost always breaks but although also it oftentimes requires

generous amount of test maintenance why is that

and what necessitates the change and uh use of machine learning and ai and in

order to achieve uh more favorable better results well uh here is a comparison

uh between selenium scrib and testrigerski and test trigger script is where you

write executable specification in english and has trigger executed emulating

uh a user interacting with web or mobile applications like a human

so uh as you can see just a sure amount of lines of code is dramatically

uh a less a four four this trigger uh but that’s not

a an issue and it’s all in its own right so uh two main issues with selenium code

is the number one well you have to be an engineer in order to be able to understand what’s going on

and where moreover uh you need to be an engineer to even understand

uh the test failures so if a test fails often times as the stack trace is cryptic and uh

engineers must be involved in order to be able to understand what is happening uh

this is one however there is even larger issue which results in that huge test

maintenance and that is a reliance on details of

implementation here as you can see

the id the test on the left relies on ids

on the name and on x path uh a little bit below

uh and that is a is a big challenge because what’s going on

is uh then people write selenium on ibm test they hook up into how

the page is implemented at that given moment and therefore as soon as the page

rendering changes ever so slightly or engineers

uh change gi framework or update the library of our ui framework and so on

and so forth then a selenium test would break for no

reason and think about it there’s two issues in in that so number one it incurs unimaginably

huge amount of maintenance uh for for no particular reason and number two

uh it makes those tests basically not helpful

be kind of useless why because this is where those changes

updates and the libraries updates and how things are rendered is exactly when engineers would expect

to or to be able to rely on end to end tests specifically

uh in order to be able to understand and things are still working or not and if uh if instead the test will fail

then the value of this is not very high all right and

what it results in is actually a pretty shocking situation the uh we have seen across the board

that on average at around 300 350 tests

it is a full-time job for a person to maintain those tests in selenium

uh think about it so in order to have more than 350 tests you need to hire

another uh pa engineer and that is exactly where

that challenge came in which i was mentioning obviously budget imagine that you have a certain budget

and you have you hired certain number of engineers which you can afford under this budget

and at some point those engineers are just full time on maintenance and what’s

happening is that you can’t build any more tests and you’re paying a lot of money to just

maintain existing tests so this is exactly the situation why

a lot of companies are stuck at around 30 percent of test maintenance

for years uh literally not able to move anywhere

so we enter results resort to uh manual testing

in order to be able to resolve this situation

and yeah so there you go so this is where you get all of those

issues coming up like this is why we have a lot of

manual testing because a lot of projects start with manual testing which is completely sensible and

they just can’t get past a certain percentages of test coverage because of combination of limited budget

uh in conjunction with this

ceiling based on test maintenance induced by test