logo logo

How to Use UI Test Automation Correctly

How To Use UI Test Automation Correctly

UI test automation is at the top of the classic pyramid of tests 🔝 This means that these tests are slow to run, brittle and you shouldn’t have a lot of them. Even still they are incredibly important to have in your test suite and you better not ignore them, otherwise, you may find yourself executing way more manual tests than you need and wasting too much time unnecessarily.

In this article, I’m going to give you some tips on how to better write and maintain the automated tests for your user interface (UI).

Why even write UI test automation?

Of course before getting into the how we should be talking about the why. UI automation frameworks and test suites demand a lot of work and knowledge. Knowledge about how to choose a framework, programming and programming languages, creation of test data and debugging, and the challenges that are intrinsic to testing in general, like boundary value analysis and equivalence partitioning.

It also demands a lot of work. Creating new tests demands as much programming knowledge as we would expect from a developer, and maintaining requires familiarity with the company’s most recent requirements. 

In the end, UI test automation is important. Even when taking into consideration all the challenges it brings, it gives us two things: speed, and confidence. Contrary to perhaps what common sense would tell, speed and confidence walk side by side in testing.

When we have a good UI automation test suite, we have fewer bugs in production, which means less developer time wasted on bug fixes, which results in more developer time being used to develop new features. As a result, we have more speed and more confidence in our features at the same time 💪

Getting the basics right: Selecting elements

One of the first things we need to have in mind is what selectors we are going to be using to get the elements in our project. There are many ways we can get an element. We could get them by CSS attributes like ID, class, or we could use XPath, a certain attribute, the text content, and choosing the wrong one for your case means more brittle tests that will have to be re-written.

Since resilience is a quality we wish to have in our tests, let’s have a look at each case in particular and see when we should or shouldn’t use them. 

Let’s say we have a button element that we want to select and click, what should we use? XPath is not a good solution, it was widely used in the past but it is way too coupled to the page’s styling, which means it is not resilient against changes.

Selecting a certain class like “.btn” or “.btn large” is not a good solution either for the same reasons. Selecting by ID is not ideal but sometimes can’t be helped, the page could have dynamic IDs or they could be updated in the next version of the page.

In general, there are two good solutions, but one is better than the other to solve this problem: selecting an element by its text is better than the previous solutions. Texts are not coupled by the styling but the logic of the business itself, unless the business logic for the button has changed, it’s likely that the text within the button will not change as well.

An example of this is a page from an eCommerce website 🌐 The buttons with the text “Add to cart” and “Buy” are key aspects of the business itself and probably will not change frequently. 

The best solution demands a little bit more work and something it cannot be solely done for the testers themselves, depending on the company. Changes in the text are infrequent but can happen. But if we had an exclusive attribute, used only for selecting that specific element, it would never change.

So, back to the button example- The tester would have to speak to the front-end developer responsible for that button and ask to have a specific testing attribute added, let’s say “t-button”. This attribute is immune to change. And now he can get the element selecting this attribute. Of course, it is not always possible but if you can do this you definitely should.

Even when you cannot find the best solution, it’s important to use the second-best solution possible. Don’t start using random solutions because the first one cannot be done. 

Going even beyond the expected in UI automation

Sometimes even when explaining the importance of having an attribute, the developers won’t write them for you for many reasons, but it’s not because they don’t like you. Developers, just as testers, are busy, they have deadlines to meet, bug fixes to deploy, project managers over their shoulders, and sometimes your needs are not the top priority, but it is also the opportunity to distinguish yourself. 

Writing your own attributes in the front end will demand that you learn some skills you are maybe not familiar with, and also you to speak to the front end team and get their approval. But if you manage to do that, you are going to be above the average automation engineer, and it will probably reflect on your next individual review, too. So take the initiative 😇

Conclusion

UI automation is hard, but doing the basics correctly is the key to being a good tester no matter the company you work for. The tech stack and tools may change, but selecting elements is a tool independent concept and can help you no matter what team, squad, or company you are working with.

In this article, you could see what is bad and what is good when selecting elements, but there are a lot more concepts to grasp and perfect when doing test automation. To constantly use the best practices in every new aspect is going to give you the best results in the long run, and certainly will make you great in UI test automation.

Hope you found this article helpful, and let me know if you have any questions in the comments 💢

Avatar

About the author

Eduardo Fischer

Eduardo Fischer is a quality assurance engineer who focuses on API and UI test automation and is currently working for an international stockbroker. He discovered his passion for testing during his time as a back-end developer and eventually made testing his fulltime job. You can find him on LinkedIn: https://www.linkedin.com/mwlite/in/eduardo-fischer-dos-santos

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now  

Leave a Reply

popup image

A new world for test automation

Join 150,000 testing & dev teams taking their web & mobile testing to new heights, using #1 FREE test automation platform, designed to help deliver quality at speed.
Get Started
FacebookLinkedInTwitterEmail