GUI mapping strategy in test automation

Question

In my practice of testing automation, I always use the gui mapping strategy, which reduces maintenance costs.

For example, if I need to identify the Google Search button (www.google.com), its XPAth will be

//input[@name='q'] 

but not

 /html/body/center/form/table/tbody/tr/td[2]/input[3] 

It is clear that in the second case, a small change in the page structure may break my test.

But maybe I missed something? Maybe if the structure of the document changes, I should know about it, and some of my tests should fail?

What do you think? What best practices do you recommend?

Answer 1

If the element has the identifier used by the / css script, we use this identifier in testing. Otherwise, we actively use our HTML for testing. By this, I mean that we can add an identifier for testing purposes only, to avoid any ambiguity. Usually we give it a prefix to indicate this, i.e. ID = "ftGoogleButton". This means that people who work only with HTML will realize that there is automatic testing associated with the element. This convention is practical because they usually only look in css / js for links to this identifier.

Answer 2

I would do the same, first select the first wording and not the second ... for most tests.

You want your tests to interrupt changes related to the functionality covered by these tests, and you want the same tests to ignore most of the other changes in the application.

So, if you check that the search for "foo" should return more than zero documents, this has nothing to do with the structure of the page and should ignore such changes.

However, in a test written to ensure that the search form is provided with a submit button, you would like to translate these assumptions into XPath, used to move from the form to the button.

Answer 3

As Krosenwold said, getting developers to standardize the html name and / or id attributes and use them is one of the best strategies. My article “Test Automation as a Development Requirement” discusses this topic and other things that developers can do to make applications more convenient for automation.

You must also ensure that all of your object identification properties are stored in one central repository to simplify any subsequent maintenance. Most commercial tools have a built-in feature, but with open source, you may need to run your own mechanism.