Selenium Automation Testing: the Superiority of AI/No Code Platforms

About Selenium and its Components

Selenium is an open source project which encompasses a variety of tools and libraries designed with the purpose of providing browser automation, oriented at performing automated tests for web applications.

Within the Selenium range we have tools and frameworks like Selenium IDE –for recording and editing functional test executions, Selenium WebDriver –used to write scripts for automating browser actions, and Selenium Grid.

WebDriver is, on one side, an API in which a user can write scripted instructions for a web browser to perform certain actions like a real user would –with a certain set of capabilities defined in common and for each browser separately, and on the other, the very driver software which runs the web browser and will handle the communication between itself and Selenium. It essentially consists in an instantiation/implementation of a web browser –any popular one like Firefox, Chrome, Safari, etc.– that the driver controls via the user scripted commands, which give instructions for several actions –like starting a certain web browser instance, getting URLs, attributes, etc., or finding elements in a web document through a specific set of parameters, and can be written in most popular programming languages like Java, Python, JS, Ruby or C# –provided language binding libraries are installed.

WebDriver is often chosen for its simplicity –especially its setup, compactness and effectiveness at driving web browsers, and also good support; Selenium provides its own-maintained drivers when thor party ones are unavailable. It doesn’t require the API to be compiled with the source code; in this way, the API works in an unintrusive way, isolating the testware from the tested application. WebDriver can also be run remotely through a server (Selenium Server), developed and maintained by the project. The combination of all these features provides for an easy browser backend use which makes the framework suitable for cross-browser/platform automation.

As of June 2018, WebDriver became a W3C standard.

Selenium Grid is the Selenium component –essentially a server application– which lets us run parallel executions, by instantiating multiple browsers (WebDriver nodes) on remote machines –whether virtual or real, which receive commands from a central server (hub) which are triggered by the client’s test scripts. This is what makes Grid a useful tool for automating tests in parallel, by being able to instantiate different browsers, and within those, different versions and configurations, hence, Grid notably saves execution time and provides high flexibility for creating test scenarios.

Selenium IDE is a complete integrated development environment (IDE) for Selenium tests. It is implemented as a Firefox Add-On and as a Chrome Extension. It allows for recording, editing and debugging of functional tests. Scripts may be automatically recorded and edited manually providing autocompletion support and the ability to move commands around quickly. Scripts are recorded in Selenese, a special test scripting language for Selenium. Selenese provides commands for performing actions in a browser (click a link, select an option) and for retrieving data from the resulting pages. [source]

Automating Tests in Selenium

Once we have our Selenium environment ready to start writing tests, a certain set of activities will be generally required to perform. That is, setting up data, performing discrete sets of actions and evaluating results. These activities’ steps should be kept as short as possible –no more than two operations in general, since browser automation is reputed as being “flaky”, but indeed, the reason is users very often are excessively demanding with it.

By keeping our tests as simple as possible and using the web browser only when it’s indispensable, we can reduce flakiness to a reasonable minimum.

One of the differential benefits Selenium tests offer is that, by design, they’re naturally able to test all components of an app, from backend to frontend, from a real user’s perspective. In this way, they offset their implementation budget by covering large business-critical components in a single activity.

A Brief Test Example

Let’s imagine we have a website which we use to create %100 custom sushi orders.

The normal flow –or ‘happy path’– would be something like this:

• Create a customer account.
• Customize your sushi order.
• Add order to the shopping cart.
• Specify shipping data.
• Check out / pay.

Counterintuitively to what many would think, we should not try to write a script covering the whole of these operations. Doing so would result in a test that takes longer to run, will be subject to issues concerning page rendering time, and, in case of failing, it will impede us from having a clear perspective of what actually failed.

So the best action course will be to create separate, independent –faster– tests for each step’s purpose.

So if, for example, we’d like to test the step Customize your sushi order, our test will need to perform this set of actions: Create an account, Configure a unicorn;

Bearing in mind that we need to create an account, we’re left with choices to make:

• Use an existing account.
• Create a new account.
• Take into account special user properties before configuration.

Any choice whatsoever that we make, we must make it part of the data set up mentioned earlier.

If each path test starts with creating a user account, it’ll only add time to the execution. By means of an API and querying a database (e.g.: config.properties file) we can make quick, “headless” operations that don’t imply expensive processes like opening a browser, navigating to the specified pages, clicking and waiting for forms to be submitted, etc.

This is where models like Page Object enter the game.

A Little Bit about POM

With the Page Object model we can treat certain UI components as objects within our test code. This saves both time and the need to modify extra classes when the UI code suffers changes.

A Page Object is a design pattern, popular for enhancing automated tests maintenance and reducing code duplication. As an object-oriented class, it serves as an interface to a page of our automated tests. This class’s methods will be used whenever they need to interact with the page UI, with the benefit that if the UI changes for the page, the test scripts won’t need to; only the code within the page object, leaving the changes for the new UI in one, separate place.

Some of the notable advantages are, a clean separation between test code and page specific code such as locators and layout, and the possibility to have a single services or operations repository offered by the page rather than having a mess of services throughout our tests.

Is Scripting still Profitable?

While the topics treated above sound like tools that can yield to the needs of our business, doesn’t this also sound like a little bit too much hassle? What about the competencies a tester should have? The implicit costs in training personnel, the implicit time consumption in setting up all our testware once a new project starts, just to think of a few possible scenarios.

Instead of using valuable time creating test scripts, why not use the power of Artificial Intelligence and let a no code platform learn changes in our code and adapt to them, making script writing/maintenance a thing of the past?

Autify’s can deal with that, and more, thanks its powerful features:

• A SaaS delivery model.
• A no code platform –no coding required.
• A GUI for recording  test scenarios then play them back.
• Test script maintenance by AI.
• AI algorithms which learn the UI changes, adapt to them and alert the QA team.
• Cross-browser compatibility, including mobile devices.
• Visual Testing engine.
• Visual Self Healing.
• Integration with Slack, Jenkins, TestRail, etc.
• Built-in reporting –no third party tools.
• An exceptional tech customer support.

Customer support is of utmost importance for us, and so we procure to provide the most human level of attention possible, considering real human beings and real human needs.

You can see our client’s success stories here: https://nocode.autify.com/why-autify

• Autify is positioned to become the leader in Automation Testing Tools.
• We got 10M in Series A in Oct 2021, and are growing super fast.

We have different pricing options available in our plans: https://nocode.autify.com/pricing

• Small (Free Trial). Offers 400~ test runs per month, 30 days of monthly test runs on 1 workspace.
• Advance. Offers 1000~ test runs per month, 90~ days of monthly test runs on 1~ workspace.
• Enterprise. Offers Custom test runs per month, custom days of monthly test runs and 2~ workspaces.

All plans invariably offer unlimited testing of apps and number of users.