Notes on Automated User (web) interface Test/Checks and Browser Automation
Most applications have some sort of user interface.
We’re talking about a user interface in the context of web applications.
With web interfaces there are multiple aspects that you probably want to test around your UI:
- behavior
- layout
- usability
- the adherence to your corporate design
and these are only a few. Manually executing this kind of test is a solution that does not scale well, then you need to go in the automation direction.
I want to share our experience at TESISQUARE (www.tesisquare.com) in the process of adopting automation. Some of the things can sound obvious but IMHO reviewing it is a must to avoid wasting your time and resources.
Generate HTML with test automation in mind
To automate you will need to be able to access in a simple way different elements in the User Interface, then the more specific information you add to identify (select) them, the better. That is why is important to add the id attribute, data-attributes, specific CSS classes.
A great approach is to add test specific attributes to avoid breaking the automated test due to application design changes. This happens when developers maybe change the id of a button or a field to follow a new standard.
You can see a working example on the gitlab.com login page. If we used the browser’s inspect feature we will notice the data-qa-selector attribute.
Testing your User Interface for I18N (Internationalization)
If you use a test recording tool like TestCafé Studio (https://www.devexpress.com/products/testcafestudio/), the first kind of Selector to access a UI Element that will be proposed will be the one that uses the text on the screen.
Look for this example on GitLab user preferences
While recording the test case steps, we can display what are all the selectors that TestCafè Studio show as different alternatives. The Best One (IMHO) to be used in navigation is the second one that uses the data-qa-selector attribute because the value will be the same no matter the User Language used in GitLab.
You can use it also if you want to test is translations are ok, pointing to it and then getting the text on the screen (see the simple HTML below)
Use the Page Object Model (POM) to protect your investment
If you avoid spaghetti code in your application and use well-known techniques to create a great application, you need to use the same approach for your test automation scripts. Your tests are part of your application and first-class citizens also. That’s why after a first exploratory/learning/proof of concept phase when you will be focused on understanding the tools and how to create something that works, you need to embrace the POM Design Pattern or your test automation effort will fail. You can read here to learn all the advantages of POM (https://martinfowler.com/bliki/PageObject.html)
Compose your ToolBox
There are lots of alternatives, maybe too much. We started our search two years ago. We found several options other than the old-faithful selenium. I wanted a tool with the record feature because this can smooth the path of adoption by people outside the developers’ universe. After trying different approaches like browser add-ons, Eclipse-based tools, etc, my choice was Test Cafe from devexpress, which was replaced with TestCafe Studio. TestCafe Studio is a commercial product at an affordable price. You don’t need to buy it, because there is an open-source engine that allows you to execute test cases you write using Javascript or Typescript. It’s important to understand that the record feature is not the silver bullet. You will need to do some scripting to make generic the test case you have recorded. The TestCafe Studio IDE is IMHO a great tool to create some kind of draft of your test cases and helps you a lot with the definition of one of the critic parts: the element selector.
IMHO just one tool is not enough. There is a good option CodeceptJS (https://codecept.io/), their approach is to write in some kind of neutral API that you bind later to one of the available helpers. Here an excerpt from CodecepJS site:
CodeceptJS bypasses execution commands to helpers. Depending on the helper enabled, your tests will be executed differently. If you need cross-browser support you should choose Selenium-based WebDriver or TestCafé. If you are interested in speed — you should use Chrome-based Puppeteer.
Besides, you can also use CodecepJS for Mobile Testing and there are API Helpers.
My last discovery was taiko (https://github.com/getgauge/taiko) and the feature I found in love is Read-Eval-Print-Loop (REPL).
All these tools are based on node.js
Test scripts are not only for testers
You can use the test scripts to improve communication between application developers and maintenance developers to make misunderstandings decrease. Why? because if I’m a maintenance developer and my fix passes your tests then I’ve surely done part of my work well.
If besides, you can convince your business analysts to use TestCafe Studio to record the use cases that prove the application issues/malfunctioning, again the developer in charge of fixing it, have all the information needed because she/he can reproduce the same use case
It’s not just launching the recorder and zero code
No, you will need to invest in the development of your test automation framework that will fit with your application. You will need to create POM files to manage with abstractions the same objects you use on your application.
Rich Widgets need special attention
On our application, we have used the Select2 JQuery plugin and this choice has created some minor issues when creating the automation.
One attention point is the dynamic nature of the ID that Select2 creates to provide as with a cool select replacement. If you fire your TestCafe Studio pointing it to http://select2.github.io/select2-bootstrap-theme/4.0.3.html
and record a test case like changing the value of a select using the mouse, and you try to replay it, probably the test case will fail with the message:
This happens because of the selector choice done by TestCafe Studio, an ID but that has dynamic nature, in select2-span_small-result-chhs-NV, the -chhs- string changes at any run.
Other uses for browser automation scripts
Test scripts are browser automation scripts, something that makes us remember the macros we use with our editors to improve boring tasks.
With a tool like taiko (https://gauge.org/gauge-taiko/), after testcafè it’s my favorite tool, you can control your browser to drive your application to the exact point where you need to regain control of your browser to test your latest development.
Think how many times during a day you repeat these actions:
1) Login ( user + password + click button)
2) open the top-level menu option
3) open the first level menu option
4) finally access the feature
why do not write a script to do this? or even more complex things?
You can also use a mix of script steps and text description when you find a bug and you need to report it to the team that will fix it. The most you write as a script the fewer other people are going to interrupt you for clarification. Besides in this way, you are creating a draft of the test automation needed to validate the fix after it will be released!!!
References
The Practical Test Pyramid
https://martinfowler.com/articles/practical-test-pyramid.htmlPage Object Model (POM) | Design Pattern
https://medium.com/tech-tajawal/page-object-model-pom-design-pattern-f9588630800bTestautomation University ..…... https://testautomationu.applitools.com/setting-a-foundation-for-successful-test-automation/
Testing and Checking Refined
https://www.satisfice.com/blog/archives/856