Many rock and metal bands, especially those that “make it big”, have that song. The song that has the “audience participation part”. You know, the part in the show, either right before the encore or right before the end of the show, where the band sings part of the chorus and the crowd is supposed to shout back the rest of the words. Judas Priest has You Got Another Thing Coming, KISS has Rock and Roll All Nite, and Helloween has Future World. Metallica, of course, has Seek and Destroy; during the final call of the chorus, James Hetfield sings “Searchiiiiiing …” then the audience shouts back “SEEK AND DESTROY”.

It occurs to me that it’s much less work to seek for something that’s easy to find. Even if we don’t know where that thing is, if we know how to locate it, it’s easier to find than something that we don’t know how to locate. My wife has a smartwatch. If she can’t find her phone, she can make it “beep” by using her smartwatch; she knows how to find it…the phone effectively yells “I’m over here!”. If I switch to an automation lens, I’m led to some analogous concepts.

UI automation often gets the short end of the stick. It’s slow (kinda). It’s brittle (it can be). It’s the top part of that damned automation pyramid (you’re not wrong). You shouldn’t do UI automation (well…)! Blah, blah, blah. The reality is that sometimes it makes business sense to do some or even a lot of UI automation. Perhaps there is a bunch of business logic in the UI. Perhaps there is no appropriate interface into the “back end”. Perhaps checking that a basic business flow works on each deploy is business critical. I can “perhaps” ad nauseum. Suffice it to say that some UI automation is valuable in some contexts. If that’s our context, it makes a lot of business sense to address as many of the “known problems” as possible to reduce brittleness and maintenance cost.

Quick aside: do the automation that provides value and skip or defer the rest, UI or not. But, to quote Alton Brown, that’s another show.

So, how do we address these known problems? One major, and usually low-effort, way is by supplying appropriate locators on appropriate HTML elements. There are some kinds of HTML elements that are almost always used during testing. These are the elements that are visible and with which we want to interact; think about what our users will want to use…at the very least, testers and automators will probably want to use those as well.

In general, the kinds of UI elements with which UI automation needs to interact include the following

  • Elements that can be typed into
  • Elements that can be pressed or clicked
  • Elements that need their values or text to be inspected

Some examples of these kinds of elements include

  • Text fields
  • Buttons
  • Links
  • Menus
  • Radio buttons
  • Check boxes
  • Pop-ups/modals
  • Elements used as page titles or section headers
  • Elements that contain results based on previous pages or interactions
  • List items
  • Grid/table elements

Developers will let us know that it is difficult or impossible to put appropriate locators on every element that we need for automation; generally, they are correct. This is especially true when developers use third-party components to help build UI widgets. Those widgets and frameworks can limit what can be specified on HTML and other UI elements. Often, the id attribute is at the mercy of the widget/framework such that its value can change on subsequent builds or code changes. No joy there. Adding a value to the class attribute can be a good alternative (I’ve done this), but some widgets/frameworks limit our ability to modify the class attribute as well. Again, no joy. While it seems that developers using these third-party frameworks severely hampers automation production, it’s usually valuable for the developers to use these frameworks, despite the apparent limitations they impose on automation development.

But, we, the automation professionals, are in luck! The W3C specifies a facility that battle-weary web UI automators can exploit with little impact to application development; this facility is called data-* attributes. These data-* attributes allow us to add arbitrary attributes to an HTML element. Why is this a big deal? It’s cool because now we can influence the developers to add these data attributes to the HTML elements with which we will or likely will interact without interfering with many of the infungible element attributes. Further, we can arm the developers with the above bullet points as guidelines allowing them to include these attributes on appropriate HTML elements during initial development. This is a more positive experience for everyone; no one needs to do “rework” to add the attributes and the automators get better locators from the outset which can reduce the initial automation effort in addition to reducing the maintenance effort for automation.

Alas, even the use of data-* attributes can be limited when the developers use certain UI frameworks and widgets. In those cases, the developers can only do what they can do. This is a great opportunity for a partnership between development and QE/QA/automation/testing; we can discuss testability and automatability with respect to the complete application’s value proposition. We can even encourage the developers to add some testability and automatability.

Generally, adding appropriate locators is a relatively small effort on the development team that can reap great rewards for the testing team. Let’s partner, make great business decisions, and help automation to seek what it needs to locate.

Like this? Catch me at an upcoming event!

Image attribution: