Question: The rate at which AI tools keep coming up feels like they are going to replace Selenium and other conventional automation tools sooner than we think. But, as of now what are the real life practical limitations of such tools? Can somebody share their project experience?

**EDIT:**

This question is basically asking to address the limitations of AI backed "codeless" automation tools like the one described above when compared to Selenium (or other "codeful" automation tools).

Answer: 
First of all: "Selenium automates browsers. That's it!" (Quote from [SeleniumHQ](https://www.seleniumhq.org/).) It provides an open-source, standardized, and widely-used interface to drive browsers, respectively, web applications. This not just enables developers/testers/… to use it for testing purposes, but also it can be used by vendors to build different kinds of testing tools/frameworks/… on top of it. Because of this, I think that a) Selenium is gonna stay for a very long time and b) the progress in the field of AI-based testing is mostly unrelated to Selenium's lifetime expectations.

> 
> "Because some things will be better done using them. Other things will be better done using Selenium" My question is to know exactly what those things are.
> 
> 
> 

Since you mention products like mabl and Testim, I assume you focus on GUI-based system testing for web applications? Today, most of such (off-the-shelf) tools that incorporate some sort of AI basically can be divided into the following two main categories (although some also fit in both):

1. Test maintenance: the tool takes care of maintenance tasks such as updating locators after changes or carrying out special checks to detect visual differences.
2. Test generation: the tool generates actual tests that can be executed. For instance, automated exploration to find broken links or the creation of regression test suites.

When it comes to test maintenance, machines can—as already pointed out by [João Farias](https://sqa.stackexchange.com/a/36567/21973)—easily process vast amounts of data, which is a huge advantage here. For instance, when the system under test (SUT) changes, you often find yourself fixing a bunch of locators. In contrast, machines can use historical data to assign new and old locators in order to "auto-heal" tests.

However, in the case of test generation, humans are usually superior. While machines can use various techniques to create non-functional tests, they have a hard time to generate actual functional tests that effectively cover particular use cases and business needs. In general, I think this relates to the testing vs. checking debate (see my answer [here](https://sqa.stackexchange.com/a/29477/21973)).
Comparing Selenium to AI driven testing is not exactly the right way to think about it. But an interesting proposition and question.

Selenium and Cypress and CodedUI and others are simply ways to automate browser tests at the UI level. We all know these are brittle and challenged with modern UI libraries. But they are mature (Selenium is 15 years old now) and function as a language to automate UI actions. When Selenium was introduced it was a godsend. But that was 2004.

I read a study recently that on average 7 selenium scripts can be fully written and debugged per man-day. Of course some take all day to just get one to work...others are faster. But the 1 script an hour rule isn't a bad way to think about any of these languages.

Codeless script generation (ie recording) was tossed out years ago as unreliable and unmaintainable. But a whole new generation popped up in the last few years that changed that (for example Test Designer in Appvance IQ). It generates your test in open-source javascript as the tester uses the application. And self-heals broken accessors at each subsequent run. Data driven of course. We have measured this at 4X - 10X faster than writing selenium scripts. But it depends on the application and skill of the QA engineer. Others have introduced recorders as well with different languages and features (Functionize, Mabel etc). I really suggest you look in to some of these. 

AI test generation was first introduced in 2017. The technology has rapidly progressed to where AIQ can generate 600 scripts per minute unaided by humans. Thats wicked fast. We cannot compare 7 scripts a day to 6000 in 10 minutes.
But how good are these? Are they valid and valuable user flows?

To date we have found that a mix of maybe 10-20 QA designed scripts alongside 5000 or so AI generated scripts provides the right balance of coverage and assurance of very specific user flows. In the end the QA team must report back up the chain that certain items completely work in the current build. Whether or not AI thought it was a valuable exercise to test that flow. So we have found this combination is critical for assurance.

For the dozens of clients using AI test generation daily from us, they indeed have dropped all use of Selenium. That was their own choice over some months. They found that specific cases can be generated faster in AIQ Test Designer (recorder) and self-healed. And the rest of the coverage generated by AI. So that left no place for Selenium.

Since Selenium is so pervasive, someone will still be using it a decade from now. But as AI test generation and advanced new recorders become more commonplace and more reliable, it does seem to squeeze out the need for true manual selenium coding as we have done for the past 15 years.

Of course, Selenium is free. AI isn't. For small dev teams free is a pretty great choice. but for large enterprises with budget, AI driven testing can have a meaningful ROI despite the cost of the technology.

disclaimer - I work for [appvance.ai](https://www.appvance.ai) and I am sharing my own experience helping teams roll out AI driven testing.