The Five W’s of automating UI testing at Cytora
Our approach to UI testing and automation
What is UI testing?
UI testing is the process of exploring and checking the user interface of an application. This means testing to see how your application, website or software interacts with a user, by checking the following:
- Functionality
- Usability
- Consistency
- Accessibility
- Compatibility
Whether you are just starting your software testing or have an existing testing process, you will know that UI testing is an essential part of any test strategy. However, this area of testing comes with many challenges and constraints that present a major need for automated UI tests.
Why do we need to automate UI testing?
Automating UI testing helps organisations save time, resources, and money on Quality Assurance (QA) as a whole. Its impact on IT and innovation in the world of QA has increased the need for Software Engineers in Test, which helps the organisation foster a more efficient way of testing.
Automated testing is best suited to tasks that are heavily prone to human error. It is not possible to continuously carry out manual and repetitive tasks with the same high level of precision each time.
How do we determine what to automate?
A common challenge with today’s modern UI development is the constantly changing interface. Coupled with the increasingly complex application features, it is time-consuming to create and maintain the UI tests over time. However, if engineered well, it can be very successful.
At Cytora, we determine whether a test would benefit from automation if it falls into any of these categories:
- Regression testing
- Testing of complex functionalities
- Smoke testing
- Data-driven testing
- Performance testing
- Functional testing
Who does the automated UI testing?
In theory, it is the role and responsibility of a Software Engineer in Test (SET) to lead any automation testing.
At Cytora, we like to do things in ways we feel works best, which means:
- SET works closely with the DevOps to make decisions on tech stack and CI/CD approaches
- SET works with the Business Agility team to lead the BDD testing scenarios using Gherkin syntax
- SET works closely with Frontend Developers daily to ensure the UI DOM is structured correctly
As Andy Knight correctly puts it — “A Software Engineer in Test must have the heart of a developer.”
When do we automate UI testing?
One of the key testing principles is early testing. To get the most out of your automated testing, it should start as early as possible and run as often as needed.
At Cytora, we run the automated UI tests as part of our CI/CD pipelines. When there are any code changes on our Frontend repository, it triggers a build and in turn, runs the automated scripts to ensure that the existing functionality is not affected by the changes.
This prevents breaking changes being deployed into production
Often we see many changes to the UI as part of the natural agile approach and methodology of incremental builds. Therefore we must attain a sufficient test coverage to ensure existing functionality remains intact with the absolute minimal manual effort required.
The SET and Frontend developers run through changes required as early as possible so that we can discuss the ramifications on the automated scripts. We have created our own elements specifically for the automated scripts to interact with the UI DOM. These are unique identifiers based on functionality and non-functionality aspects of the UI. The element will follow the data-testid=”” format with the value of that particular component and function.
For example:
Here we have two tabs - Company search and Property search. They both receive unique identifiers:
data-testid=”cytora-tab-label-company-search”data-testid=”cytora-tab-label-property-search”
By creating this library of unique identifiers early in the design stage, we are also able to build the automated scripts early, which will be pushed along with the code that introduces this change.
Where do we automate UI testing?
At Cytora, we have an extremely strong and talented team dedicated to ensuring our platforms are top tier. With their help, the SET has been able to integrate the automated UI framework with CircleCI and Concourse.
CircleCI is where we build and configure the pipeline, which then triggers the deployment in Concourse.
When the build is triggered in CircleCi, it sets up a remote Docker engine and begins to build the Docker image. Once this stage is completed without errors, it will finally then authenticate and publish the image to the GCR (Google Container Registry).
The build is now complete and CircleCi will automatically trigger the deployment in Concourse. Concourse then pulls this image from GCR and run the acceptance tests in the Pipelines.
On the less frequent occasion where our tests fail, Concourse pings an alert to the engineers of Cytora via Slack specifically set up for our alerting process. At this point, the deployment in Concourse is highlighted red and marked as failed. Users can debug and diagnose the failure by taking the stackTraceId printed in the Concourse console and searching on our Browserstack dashboard for the failed test/s.
When the automated UI tests run, they connect using Selenium to our Browserstack account where we execute the UI scripts across multiple browsers and versions. This provides reassurance to us that our customers’ operating on any of the browsers or versions are still able to use the UI comfortably.
Conclusion
When it comes to being successful in Quality Assurance, it’s vital to understand the importance and benefits of automating UI testing. The what, why, how, who, when and where of automating UI testing highlights this, and gives insight into how we achieve this at Cytora.
We should automate UI testing not just to ensure the absence of bugs but also to ensure the presence of value. If we automate, we save, we grow and ultimately we become more successful.
