Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Highly Maintainable and Flexible UI Test Automation - Part 1

DZone's Guide to

Highly Maintainable and Flexible UI Test Automation - Part 1

This post draws from years of experience to guide you through good practices for UI test automation with various tools in the QA process.

· DevOps Zone ·
Free Resource

Read why times series is the fastest growing database category.

This will be a story about the history of QA process in the division where I worked for over six years, related mainly to automation. I think that when I share it with you, you will not make the same mistakes and reuse our good practices from the beginning. I think the best practices is to learn from your mistakes. However, I just want to point out that most of the times we did the best we could in the current situation. Because achieving of the things mentioned cannot happen in a day or two. Moreover, there is always this mixture of money, time and expertise of the people involved. I will share with you practical tips that I encountered during the whole process.

Selenium IDE Era

Selenium IDE tests - how do you precisely arrange your tests, even simple stuff like login on the site? Do you always use hardcoded users? Do you test on your test DB with predefined data? We had some steps where the tests always first navigate to the registration form and registered a new user for the tests. However, as you can imagine this took more than 20 seconds for every test. We needed this since if you use the same DB every day if you use the same clients and add products, the later did not disappear mysteriously. Besides, the deletion of products, if you do not have the required API, is even harder.

Selenium IDE test

Selenium RC

We executed these tests nightly using Selenium Remote Control via hard-to-understand batch files.

Selenium RC Results Report

Batch File Running Selenium RC Tests

Dos and Don’ts

  • Put your tests in the same source control.

  • Developers should be able to see your tests and help.

  • Developers and QAs should work in close collaboration.

  • Do not leverage on recording tools for long-term automation. Full-scale automation like 100+ tests or something too complicated. Do not use recording tools because the maintenance of the tests is much more significant compared to the time needed to write the test.

  • Use the same technology and languages if it is possible as your developers. Otherwise, they cannot help you. We helped each other all the time. We all wrote C# or SQL, and we could do each other code reviews.

  • The dedicated automation teams are not a good idea. Once I thought that this is a good idea. You can most of the time do automation and not manual testing. However, you need to know the domain you are testing. One good developer without previous experience in testing or the field cannot be a good fit.

  • Hire QAs that have programming knowledge. If you want to achieve highly maintainable test automation and have reliable tests, which code is like the production one, always hire QAs that have a programming background. All of my colleagues were skilled programmers too. Maybe not all of them were as good as our developers but had enough skills to write high-quality tests. A long time ago, this was not the case and when you hired someone who does not know how to write two lines of code is okay to prefer the usage of recording tools. Even then, it can be hard for him to write maintainable tests.

Soap UI Era

Another example why we did not want to use test recording tools or tools with UI to maintain tests is Soap UI. We had to develop, and test lots of web services and our team needed a proper way to test and automate them. The cheapest solution was the free version of Soap UI.

Soap UI Test

I developed many tests something like 2-3 workflows with more than 100 steps. Even we bought the PRO version of the tool for all of our QAs. This way we could use the program's advanced features such as using DB connections and conditional and iteration constructs.

However, the parameterization of all of these big arrange scripts was hell. With so many tests, the product was not stable enough back then for so many tests. I sent lots of support tickets since there were issues all of the time. Once the support person asked me to send him our tests so that he can debug. He was shocked because until then he did not expect that someone is using the tool in such a scale. He was- "How many tests, o my God!"

Dos and Don’ts

  • If you code your entire test using the same technology as your developers, you can usually reuse some of their code for some cases. For example, you can reuse the creation of test clients instead of navigating every time to the registration form. You can always copy the code to your solution, but when there is a change in the way of creating the users, you should spend a time to update it too and waste time. However, keep in mind that reusing production code can also lead to using a buggy code for tests.

Test Data Equipment Service

The next step from our journey was that two people from the largest product back then join us to help to improve our tests. We started to use half coded, half UI tests using Test Studio and Testing Framework. Moreover, they developed a web service that used factories and other production code to arrange and clean the state of the tests. Most of the code was utilized in the integration tests of the production code.

These people were skilled programmers, but they did not know our domain. When they left, there were problems related to names of the methods and workflows.

Test Data Equipment Service Diagram

Test Studio Visual Studio Integration

For a while, we used a hybrid solution. It used the so-called coded steps.

Hybrid Solution

Hybrid Solution Coded Steps

Dos and Don’ts

  • Do not use hybrid solutions- code + UI tool. If you have skilled Automation QAs. Never, ever do not use such combination. It does not give you all of the benefits of the programming, also keeps some of the problems of the UI tools. Such as hanging and slower writing.

This is the end of part one. I am going to continue the story in the next article.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

Topics:
devops ,ui testing ,test automation

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}