Using artificial intelligence (AI) in testing to visually expand the accessor pool increases accuracy, productivity, and almost completely eliminates maintenance. The number one reason test cases get re-written is that an accessor has changed. Using AI and image recognition provides more ways to recognize that accessor, which improves the stability and reliability of the test. It’s a transformational way for a test platform to recognize web elements that makes the traditional means of using accessors, or locators, arguably almost obsolete.
What are accessors and how do they work?
Accessors are the way that a test system can recognize an action, or an element, in an application, especially in a web application. What’s an element? An element can be a button, link, form or a dropdown box. For the last 25 to 30 years, testers have recognized elements like these by looking deep within a browser at certain code snippets that tell them what’s unique to that element. Those include things like XPath, Element ID, Name, Link Text, or CSS Selector. It might include some parent-child relationship, or a relationship with the code that is in there. In addition, there are several kinds of code within the code. That’s how testers find that element again and again. For example, when the tester does their next build and goes to that same page, the test recognizes Element ID 27. Then it proceeds to something else. That’s how Appvance and others automate website testing.
Everybody Uses Them
How Appvance Extends Accessors
Now that applications are more complex, when the application itself is compiled, it spits out that browser code that isn’t compiled. It then dynamically changes all those accessors and locators to something else. So that means you write a script that says, “On this page, click Element ID button four,” but the next time you run it, button four isn’t button four anymore.
It looks the same, but button four is now button 82. And the next time you run it, it’s button three. All of a sudden, your accessors are not stable. That is called instability in accessors. They’re literally not stable and can no longer be counted on. It’s impossible to write a test stably that tests the code and the web application. Every time you run it, the test fails because it never found that button. Button number four is no longer there as far as it’s concerned.
It’s now possible to do it visually with AI. Appvance has expanded its accessor pool because not all accessors are always bad. Many of those accessors are very good, stable, and can be used all the time. AIQ uniquely and powerfully captures all the practical accessors to locate an element. If the element ID changes, AIQ might go to XPath, and that parent-child relationship might be stable. AIQ uses all of these different approaches.
Sometimes, however, they all change and if this happens, they can’t be used. Appvance is now expanding the accessor pool to include the X-Y coordinates on a fixed-size browser. For example, if you fix the browser, that button should always show up in the same place, for that page, for that same action. AIQ also uses visual accessors. A visual accessor means not only is the code looked at in the page, but the system also takes an approach to viewing the page like a human would. If it can see a button, it’s going to understand the boundaries of the button automatically and use the visual element to identify that button moving forward. It also recognizes its location on the page. If you have the location of the button and its visual appearance, as well as all of the other accessors available, it will continue to identify the element. Now, when you come back to test the page and all the code-based accessors are gone, there are the visual options for identifying the button and the test will still run.
Very few companies have ever done this. It’s very hard because you have to use AI and image recognition to recognize that’s the button you saw before. It works the way humans do. The test would say, “I know what that button is. I know what it says. Actually, I don’t care if it even moves around. I just know what it is. So therefore, I’m going to execute it.” Appvance expanded the accessor pool to give it more opportunity to use additional accessors to locate the element when running a test. That improves the stability and the reliability of the test and reduces maintenance because otherwise, a person would have to maintain the test by rewriting part of it because it can’t find that element.
Real-time Accessor Fallback
Appvance optimizes the accessors in priority like it does with its accessor libraries, then AIQ automatically puts that into priority ranking. That priority is determined by the stability of the accessor. In other words, what you can count on every single time. If that doesn’t work, AIQ does what’s called accessor fallback, to the other accessors. Also known as self-healing, but in real-time. AIQ can self-heal a test as it runs, by looking at the entire accessor pool and falling back to other accessors, thus you are not just stuck with the best one. With real-time accessor fallback (or real-time self-healing), AIQ uses the best accessor and if in three builds from now that doesn’t work, you can still try the old ones.
Appvance has been using this kind of technology for several years (accessor fallback); the added visual accessor options will be slowly rolling out to everyone in the coming months.
To learn more about Appvance’s web application testing capabilities, schedule a call with the Appvance sales team.