9 Tips to Speed Up Automated UI Tests
Interested in how to speed up automated UI tests? Learn effective and efficient tips that will help you perform UI automated tests faster and more efficiently.
User interface automation (UI automation) is a testing process in which scripts are executed by an automated tool on a graphical user interface (GUI). It requires interaction with the browser and its elements to perform actions such as clicking and typing to test the functionality of the application. In a GUI, you get visual representations such as buttons and icons, and interact with those icons using your mouse or keyboard rather than using text messages or the command line to perform tasks or functions.
Because UI automation interacts with more elements and has many dependencies, it is considered slower and more vulnerable than other types of tests such as API tests, database tests, and unit tests. UI automation also tends to create a wide variety of user scenarios, and the application's user interface, along with its locators, can change and cause crashes. UI automation also requires interaction with other dependencies, which can lead to bottlenecks. Despite all this, there are ways to speed up UI autotests. And here are some of them:
Use the application's API and database layers.
The application API layer executes commands in thirty five times fasterthan the user interface layer, and can be used in the following ways to speed up running autotests:
Create test data using API – The data required for test automation in a specific format can be quickly created using API. For example, if you want to provision a certain number of users with specific profile features, then you can use the API to create those users much faster than if you went to the GUI and tried to create those 10 or 100 user types. Doing this through the API will save you a lot of time. There will be fewer errors with this approach, because if you are going to create 20 users, and you run the profile creation test 20 times, then anything can happen during the creation process. The Internet may be slow or the GUI may take a long time to load, which will affect how quickly you can successfully create a profile.
Cleaning – Cleaning via API can help speed up UI autotests. If we use the scenario mentioned above where we have created 20 users and assume that for each of these users we have added 10 items to the cart. When automating testing, we want to make sure that whatever we do in one test doesn't negatively impact other tests. In this case, we need to remove products from 20 users' carts. If we were to do this through the UI, we would have to log into each user's profile, go to cart, and then delete each item from the cart (unless there is a delete all items button). This is a cleanup step that can be done very quickly with one or two API calls.
Verification – Verification in tests helps us determine whether the actions we took were successful or unsuccessful. We can make API calls to verify that a user has been created and also to verify that purchases have been made. This would reduce the time spent in our tests instead of doing it through the UI.
In the same way, you can save time by creating test data, cleaning and validating it at the database level. I used database queries in projects to find specific types of users that I needed to run tests under certain conditions. For example, I was on a project where we sold flowers for people who had passed away. Each funeral home had its own business logic, as well as the date of death of the person. I used the database to get users who were at a specific funeral home and died less than 5 days ago. Using the results of this query, I could generate a URL that took me directly to the person's death page. Thanks to this URL I was able to run my tests without any problems.
If I hadn't made this request, I would have had to go to the site's home page, find a funeral home, wait for it to appear, and then filter out people who died less than 5 days ago, then click on that person and wait for the page to load . This would take longer than running a database query.
If you add this method to other tests with similar conditions, the execution time will decrease and thus you will save a lot of time using the database. This way you can speed up UI tests by using APIs, databases and other testing methods to manage Setup and Tear Down tests.
Visual regression instead of running specific UI tests
Visual regression is a process by which an application's graphical interface is examined to ensure that it maintains a certain appearance. This is done by comparing the original or reference images with what is currently displayed. These comparisons are made during regression tests or whenever something new is added or some changes are made, and new screenshots are collected to compare with the original.
Let's think about the tests that a UI Automation test suite has that it doesn't handle well or that would be better done with visual regression. Checking font size and color, spacing, alignment is best done using visual regression rather than UI automation. Visual regression will also be better at finding errors in scripts when:
An element is present on the screen, but is in the wrong place, has the wrong color, or is blocked by another element
Parallel execution
Test automation can be run sequentially. That is, tests one after another. When using parallel execution, you can significantly increase the speed of autotests. Parallel execution allows you to run several autotests simultaneously. This way you will have multiple browsers open and you will see your tests running simultaneously.
When you have multiple sets of tests (suites) such as login verification, checkout, and search/filtering, instead of waiting for the login suite to complete and then running the checkout suite, etc., you you can run all three suites at the same time. In many test automation frameworks, you can control the number of sessions and therefore the number of parallel threads. You may want to do two sessions. Or maybe three or five. It all depends on the types of tests you have.
The advantage of this is that it reduces the time required to run the entire test suite. If all the tests took 10 minutes to run and you decided to run it in parallel and split it into two sessions, that would mean it should now take five minutes. If you increase the number of parallels, it will reduce the execution time.
This will also help you test on more mobile devices and browser combinations. You can have one parallel execution designed to work in Google Chrome, one for Safari, Internet Explorer, Firefox, and so on. This means you will have 4 different sessions for 4 different browsers and the time will be reduced compared to running sequentially.
When running tests in parallel or distributed, be aware of tests that have dependencies. WebdriverIO has the ability group dependent testsso that when running in parallel, these tests are executed in the same session in the specified order.
4. Distributed execution
Distributed execution provides the same benefits and speed improvements as running tests in parallel. Distributed testing or distributed execution is when tests are run on many different virtual machines or computers in the cloud. Cloud services such as Docker provide the ability to deploy various servers or environments that can be used to run tests.
Generally speaking, end-to-end or UI tests are intensive processes that can sometimes take up a lot of processing power. Distributed execution in the cloud increases testing speed; The machines are more powerful, have more memory, space and allow you to run tests in parallel, so UI tests will run faster. Distributed execution also eliminates the need to manage servers and browser versions. This allows you to avoid wasting time setting up new environments. These environments can be configured on these computers or resources in the cloud. These cloud services are updated whenever new versions of mobile phones or OS are released, so you don't have to physically buy a new mobile device.
Parallel and distributed execution will help speed up testing and reduce the time required to set up new environments.
How parallel and distributed test execution saves time
Parallel and distributed test execution saves time by allowing you to:
Headless browsers
Browser automation can be done in both a regular browser and a headless browser. A headless browser works just like a regular browser, but it does not have a graphical user interface. So when you run your tests, you won't see the browser window pop up and the actions being performed. Interaction with the headless browser is carried out through the command line interface.
If tests are running in a continuous integration pipeline (CI pipeline) such as GitHub Actions, Jenkins, etc., then there is a very high chance that the UI tests are running without rendering the UI.
Headless browsers do not require a visible UI, and this makes headless tests much faster than browsers with a UI. When running tests in parallel, UI-based browsers use a lot of memory compared to Headless browsers.
As with all the tips I've shared so far, you have to consider the specifics of your specific test. Be aware that some application features may have unexpected behavior in headless. Headless browsers do not simulate exact user behavior, and some tests may fail due to the speed at which they are run. Additionally, regular users don't use a website headless, so it's equally important to run test scripts, exploratory testing, visual regression, and other forms of testing on a regular browser. You need to ensure consistency in the functionality and user experience of your web application.
How headless browsers speed up UI testing automation
Headless browsers increase the speed of UI testing automation because they:
Reduces the time required to execute automated scripts compared to a GUI browser. GUI browsers will have to load CSS, images, render HTML, and this will increase the time it takes to execute your script.
They are useful when the test server does not have a GUI. This applies to most cloud servers that can be used to run parallel/distributed tests.
You can try out headless browsers in various test automation frameworks such as WebdriverIO, Cypress, Selenium Webdriver, Puppeteer and others.
Effectively manage Setup and Tear Down tests
We discussed how APIs and databases can be used to create the specific environment needed to run your tests. Using APIs, databases, data files, custom functions, and other testing techniques to organize the Setup and Tear Down process of your test environment can significantly speed up the execution of your UI tests.
Create application pre-configuration steps that are required for your tests. This is especially true for unique scenarios where user data or other data must be in a certain state before tests can run. You should not prepare scripts through the GUI. It's better to use other components and approaches to perform this pre-configuration, so that when you start running a test, you only need to test the functionality you're directly testing.
Think about how and when you do Setup and Tear Down. They can influence test results and cause test failures if not performed correctly. This can also increase test execution time.
Test setup is the process by which the necessary data, users, or environments needed to run the tests are created. Tear Down is the opposite process where you remove or clean up actions performed during tests to ensure they do not negatively impact the state in which data or environments need to be in order for other tests to pass. Ideally, Test Setup should be done before running the test. So if you have a large database that you want to set up early to make sure your environment, data, and users are in a certain state, do it at the very beginning.
Tear Down should be done after scripts where necessary; otherwise do Tear Down when all tests are completed. This saves time compared to setting up the same or similar script before each test and then removing and repeating the process, thereby increasing the time it takes to run the tests. Setup and Tear Down require some planning, but when done correctly can improve the speed of UI automation.
Use of cookies
Cookies allow browsers to track, personalize, and store information about each user's session. Without cookies, you will have to log in again after you leave a website, or re-create your shopping cart if you accidentally close a page.
Cookies are an important part of your online experience. They allow you to manage sessions, save login information and preferences. Cookies are also used for personalization so that you receive tailored advertisements and to track activity. If you're on an online retailer's website and have previously viewed an item, it may fall into the category of things you liked or previously viewed. This helps improve your online shopping experience.
Cookies can be used in web automation to speed up UI testing. This is achieved by using information stored in cookies, such as log data, to preload test scripts. If you don't want to log in through a GUI every time, or you're running a specific test, you can use cookies to preload your login information.
A project that has feature flags such as A/B testing is a good candidate for using cookies, since with A/B tests you are not sure which version of A/B testing will appear, and with test automation you will only want to test a specific scenario. Cookies can be used to disable feature flags and specific features. This way your tests will always know which script will be loaded. Scenario A or B.
By storing information, enabling and disabling features, and tracking and storing information about user sessions, you can use cookies to control the state of the user interface to improve the speed of the UI.
Various frameworks provide the ability to use cookies in test automation. Selenium Webdriver has the addCookie command. It is used to add a cookie to the current browsing context. It takes a set of defined JSON objects and shows you examples in different languages that Selenium Webdriver supports.
For this to work, you must be on a domain for which the cookie will be valid. You can pre-set cookies before interacting with your site. Once it loads, these cookies will be there. You can also manage various cookies and there are other commands you can use with Selenium Webdriver.
WebdriverIO also provides the ability to manipulate and interact with cookies. The command is called setCookies. A cookie can be set for any page without being on that page and details how you set different cookies.
Pay attention to the specific test automation platform you use. Learn how to integrate cookies into test automation and speed up UI testing.
Use navigation shortcuts
Navigation shortcuts speed up the test by eliminating unnecessary steps. Going directly to UIautomation.com/profile/edit is much faster than if
Go to section uiautomation.com
Click “Login”, then
Click Profile
Click “Edit”
Wait for all these pages to load
Going directly to a page is one navigation, rather than navigating and then going through a full list of steps before you get to the page.
Using all the tips mentioned above, such as setting up APIs and databases to create URLs that you can go to directly, will also help, as will using cookies to preload login information so you can go directly to the web -website.
Creating Atomic, Non-Repeating Tests
In addition to these tips, in general, when automating testing, make sure you create atomic, non-repetitive tests. Don't repeat several of the same scenarios over and over again. You don't want the login to be repeated over and over again in multiple places. Instead, you can use cookies and navigation shortcuts to reduce this. Avoid using a very long suite, which will last a very long time and be prone to failure.
Your tests should be very small and focused on the specific problem you are trying to test. Use other levels of the test automation pyramid and UI automation to test the things you need.
How to speed up UI tests?
UI automation is a part of end-to-end tests, which are slow and take longer to execute compared to integration and unit tests. To speed up this process, evaluate your tests and choose the method that best suits the project. Think about other layers of the application that can be automated, and don't try to do everything at the UI layer. You can also use other levels to help with your tests. Cookies, headless browsers, parallel/distributed execution, and navigation shortcuts can all help speed up UI autotests.
