Bake in Software Test Automation from the Start
Simply put, it’s difficult to build automation. It takes a degree of technical expertise to script tests, especially for advanced software test automation, not to mention patience and collaboration as you work with other members of the organization.
Preparing for test automation, however, is much easier — no matter what you’ve heard. And it’s the key to successful implementation of advanced test automation. The magic associated with software test automation, such as self-healing capabilities, all starts at the planning stage. It’s not a sprinkle of fairy dust; it’s a well-designed and well-planned capability.
Codeless automation is no different. Some believe codeless automation can only automate simple tests, but that’s not entirely true. The same foundation that supports advanced test automation scripts also enables codeless automation to thrive. While it might make sense to begin with simpler automated test cases for the sake of alleviating a backlog and getting familiar with the product, there’s no reason why codeless automation tools can’t handle sophisticated tests — again, as long as you’ve planned appropriately.
Here's how to approach software test automation with a codeless automation tool, such as Applause Codeless Automation.
The concept of inclusive automation
Most programmers are familiar with the concept of inclusive design or universal design, where you create a product to be usable by the largest number of people possible. This concept is more important than ever as organizations strive to create accessible products, and it also informs how we should approach software test automation.
Traditionally, a software developer in test (SDET) uses code to script automation, particularly for complex cases. Software testers might not have the technical know-how to understand, let alone maintain, those tests. This creates a big problem when personnel changes occur or the scale and scope of test automation grows beyond the SDET’s control.
Inclusive automation resolves this issue. Codeless automation products, like Applause Codeless Automation, make it possible to create automated tests without manipulating code. You interact with an interface, and ACA does the technical work for you.
But, while codeless automation abstracts away code, it isn’t the only way to make use of inclusive automation. The same identification tags that codeless automation relies on can facilitate scripted automation as well. It’s all about making your test automation smarter and more resilient — not more complex.
How to facilitate automation — and accessibility too
These days, test engineers and developers must validate both web (often with an open source framework, like Selenium) and mobile apps (often Appium), but the latter introduces a unique challenge when it comes to software test automation.
For example, in web automation Selenium has access to the whole document, which makes it easy to locate individual elements to validate anywhere on the page. When looking at a mobile application through Appium, only what is in view is addressable, and on top of that the number of items in view can vary depending on the device in use. This issue alone makes it very difficult to build automation for mobile devices. For example, an element can be at the bottom of the page one moment and then move to the top as the user scrolls, which can create inconsistency in the test script
Worse still, improperly coded elements leave gaps in accessibility coverage, an area of increasing importance. If people with disabilities can’t access your apps, you miss out on a big segment of your user base and open yourself up to legal challenges.
For this reason, it’s important to properly gear your apps toward inclusive automation, which includes details baked into the code. Whether the test automation code is written in Selenium, Cucumber, Appium or another language, include these elements to help the automation locate your elements:
ID. Every element has a unique identifier, which is called resource-id for Android and name for iOS. Your software test automation should act upon these IDs, rather than position on the page, to remain consistent. IDs can include parent and child IDs to further classify and specify the area under test. These unique identifiers provide stable anchors on which the automation can act or where assertions can be added; they don’t change as the user interacts with the app or page.
Content description. Called content-desc for Android and accessibility-id for iOS, this descriptor explains the element’s purpose. The content description is helpful for programmers to distinguish between UI elements, but especially helpful for people with disabilities, who rely on screen readers to relay these descriptions to them.
The above are becoming a standard practice for automation. In fact, some IDEs prompt developers to include these element attributes, but it must become commonplace. These IDs aren’t optional if you want to implement functional and advanced test automation that won’t break.
ACA uses IDs as automation hooks, which enables developers to change the UI or add features as needed. So, if you use ACA, there’s no coding expertise needed to make your automation more resilient. You can record and add assertions to tests in mere minutes.
The limits of software test automation
While codeless automation can handle many of the advanced test automation cases as scripted tests, there are some instances where it might make sense to turn to automation expertise, such as with our Automated Functional Testing solution.
Some tests are still better executed manually, not because of the limits of codeless automation, but rather the limitations of test automation as a whole.
It’s very difficult to marry external data and on-screen data in software test automation. This comes into play with external API calls, commonplace in all apps today. For example, it’s difficult to automatically validate a login through Google or Facebook, because each app behaves completely differently depending on a number of factors, such as whether it is installed and the OS it runs on — and can change any time with an update. Synchronizing two systems is one of the most challenging problems with any type of automation.
Still, these are areas that automation — and Applause Codeless Automation, more specifically — will be able to address in the near future.
Plenty of potential with software test automation
With a proper commitment to enabling advanced test automation and accessibility, organizations can achieve remarkable things. So, why aren’t more organizations doing it? The simple answer: features, features and more features.
It’s not easy for dev organizations to pump the brakes on developing new features to pay down technical debt. For some, there’s an ever-present attitude of, “if it ain’t broke, don’t fix it.” So, things like code refactoring, desiloing and other digital transformation initiatives are put off, largely because of the requisite resource commitment.
Technical debt doesn’t register or excite users, but it’s a necessary endeavor. Performance inevitably suffers if you don’t pay down technical debt, which is why many of the great technology innovators commit to reduce it periodically. Achieving advanced test automation through inclusive automation is one of these areas where you’ll have to pause progress on core competencies to benefit the organization in the long run.
I’ve worked at companies where we’ve planned for this work from the beginning, and I’ve worked at companies that didn’t want to pause progress to achieve these goals. In my experience, it’s not very difficult, and the risk is relatively small. The best way to succeed in this effort is to roll advanced test automation planning and strategy directly into your SDLC. It’s not a one-and-done task; it’s a constant effort to properly identify app elements and improve automation around them.
It takes commitment, but when it comes to software test automation, the sky is the limit — and we should reach for it.
