I want to do some write-ups on different testing tools. Because even if though I believe in being tool agnostic, tools are still an important of the overall testing experience for many tests, and hopefully providing some basic insights on the different tools, can help to better equip testers and teams in knowing which tools to use or getting the best value out of tools. In these first few posts, I want to focus on Tosca, not because it is my favorite tool or one that I use widely, but largely because it has just had a recent big update which I feel is quite important.
As I’ve mentioned in previous posts, I’m not the biggest fan of commercial testing tools. Your success in software testing and automation lies in the design of your software and frameworks themselves and not in the tool. That doesn’t mean that tools don’t offer good benefits and services that can add value to any organization.
One of the recent big features that have come out of a testing tool of late has been the support of the new ARIA framework in Tosca 16.0. Tricentis (the developers of the Tosca tool) have been in the software tooling business for over 20 years and so it’s no surprise that they have further enhanced their standard automation tool with several new features that refine the product further. And there are many great features that I will detail at the end of this blog post.
The one which I have found most exciting though is the support of the ARIA framework. What is the ARIA framework and why is it so important? So, what is the ARIA framework, and what makes it so important? Because it targets a previously very underdeveloped portion of the internet that few testing tools and indeed companies even supported in their development or testing efforts. Those with visual or audio disabilities. Or as I prefer to call it, differently abled.
In a tech world where accessibility and usability are such important foundations for an application to succeed, it is a surprise that few testing tools have made it easy for companies to test and automate these features in their applications.
For those unfamiliar, ARIA stands for Accessible Rich Internet Applications and is essentially a set of roles and attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to those who are differently abled.
It supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is not otherwise a mechanism. For example, ARIA enables accessible JavaScript widgets, form hints and error messages, live content updates, and more.
This is a great set of protocols and functions that open up applications quite significantly for those that need them. What has made the testing of these features previously a challenge is that the various technologies providing this are outside the domain of the web app itself and therefore not always identifiable or controllable within the web app itself.
Aria essentially consists of three main components: Roles, States, and Properties, which are defined in more detail below:
Roles
Roles are used to defining a type of user interface (UI) element (i.e. role=“ROLE_NAME”). Once a role is set for an element, it does not change.
These roles can be something that is abstract and therefore doesn’t sit directly in the code, to something that is embedded into a widget, document object, or form of some nature (like a banner).
States and Properties
States and properties can be applied to elements and are used together to support ARIA roles existing on a page. States can change on their own or with user interaction (i.e. aria-checked and aria-disabled), usually with JavaScript. Properties rarely change once they’re set (i.e. aria-labelledby and aria-describedby). These states and attributes can be carried across drag-and-drop, widgets, relationships, and live region attributes as well.
I wouldn’t expect you to become familiar with all of these different aspects of the ARIA framework, but needless to say, it bringing big changes to the way browsers interact with some of these objects to make things more usable for different people, testing tools need to also cater to these changes to allow for automation and sufficient quality control of features implemented using the ARIA framework.
Tosca 16.0 is able to identify the existence of these specific ARIA objects directly in its object identification tool and allows testers to therefore make changes to the different roles, states, and properties of each of these elements to and control how they are utilized in the browser and ultimately verify that functionality as well.
But what about AI testing tools
There are some visual testing solutions that try and test for this, but none provide a solution that is as easy to use, while also giving the testing team full control over the functionality they are testing for rather than relying on AI to try and identify compliance with this. Additionally, there aren’t any AI tools that cater directly to the ARIA framework and so while they may be able to test an application from a variety of different settings and resolutions in a very efficient and automated manner, without being able to tap into an application’s specific settings around ARIA, it’s not going to be able to test this effectively.
Tosca allows the testers to bring much better reliability into the automation space with a built-in library that allows testers to control the ARIA framework and therefore deliver not just great functionality into their automation, but great accessibility too.
A focus on accessibility
There have been a lot of articles written recently on the topic of accessibility and it has featured quite heavily in several conference topics I have attended. It’s clear there is a need within the testing community to test around issues and ensure that software is functional for all and it’s great that we are finally starting to see some growth in this regard.
Hopefully, many more tools will be looking to adopt this approach in the near future – including the open-source domain, to allow more teams to equip their testers with the ability to ensure accessibility.