Great QA Tags

When automating against a UI, it can be challenging to locate elements. It’s also challenging to come up with a locator that’s somewhat immune to change.

A classic example is an absolute locator, like this:

//*[@id="primary"]/div/div[2]/div[1]/div[2]/span

Probably you already know that’s gross, because if that element were to move anywhere else in the DOM, you’ll be updating your locators.

But in case you didn’t already know: please don’t specify your locators that way.

advanced-form

Building In Testability

The best strategy is to tag your elements according to something else on the screen.

What this does is allow you to construct tests with a minimum of dipping into the DOM to find elements. It can also allow you to spend a much smaller amount of time in your automation code too.

Consider this example form. I use this guy as an example a lot, because it’s simple. There are 3 text fields, one dropdown and one checkbox.

In the DOM, these fields might look like this:
ex1.html

Although you could use the id tags, in this example it appears that these are generated at runtime. It’s generally not a good idea to locate based on attributes that can change at anytime.

What some people do is ask the developers to put QA tags into elements for them–tags that are just for automation, that allow for foolproof locations.

And a great way to put tags in there is to refer to something that’s on the screen, that appears to be associated to that element. 

Here’s what that would look like in the DOM:

ex2.html

Note the addition of a new attribute, qa, for each element. Each one is set to the value of the label next to the element.

Now, when you want to locate any of these elements, you don’t even need to look at the DOM. If you know ahead of time that a text field or a select list will have a qa tag named for the label next to it, then your locators would look like:

//input[@qa='Name']
//input[@qa='Email']
//select[@qa='Investment']

And, if you wanted to take it a step further, you can enclose those in methods that take in the label name as a variable:

def enter_text(String tag, String text) { 
   locator = "//input[@qa='${tag}']"
   browser.findElement(locator).value(text)
}

def select_option(String tag, String option) {
   locator = "//select[@qa='${tag}']"
   browser.findElement(locator).select(option)
}

Rule Bendin’

Asking developers to add something into elements to help with automation is a great rule to bend.

Not only does it promote collaboration, but also helps them understand more about the challenges you face as an automator. It also helps get testing done faster.


Sometimes it doesn’t take huge earth moving ideas to get your team to the next step on the path. Sometimes it’s little ones, like this. If you need a little extra Brain Juice–or maybe just a different flavor–I could help. Contact me below and let’s discuss your challenges.

Advertisements

One thought on “Great QA Tags

  1. The idea is excellent, however I don’t personally agree with your samples implementing them.

    Consider a test case for a web-based user registration page which calls for:
    * Required user name and password labels have either (Req), or “*” suffixes
    * On an password textbox entry, the password label font should appear bold red, the password textbox border should be appear bold red and the password validation label (standard in ASP.Net MVC for example) should show and display warning the user of the valid characters & length needed). The overall page validation label should warn of a problem with the password field on form submission.

    Consider test case for localisation:
    * If the UK flag is shown, label1 should read “welcome, Alex”
    * If the Australian flag is shown, label1 should read “G’day, mate!”

    Developers should, IMO, ideally specify all relevant form elements in the manner above and not attempt to second guess what might be included in automatation now or in future… labels, validation labels, divs which have dynamically changing behaviour etc. and not just user entry fields. Email is misleading. EmailValidationWarningLabel, EmailDesciptionLabel and EmailTextBox are far more desciptive and allow for automated tests sets to be enhanced later without additional new UI changes or application builds being made.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s