What to ask programmers before automating with Selenium

Question

What points should I discuss with frontend programmers when preparing a product on which, as a tester, I will use Selenium to automate?

I am referring to things like no dynamic ids for elements etc. Any ideas?

In my example, they will use AngularJS.

Answer 1

Agreeing on good element and attribute identifiers is essential with web applications.

Identifying elements is done by developers, designers and automation programmers.

In a traditional waterfall environment with most of the requirements and specifications placed up front you can agree that, for example, all elements that will be used, checked, clicked on, etc, have unique IDs.
Another option is to decide that all elements that are used by automation will have data attributes for automation. For example <input class='smooth' data-primary-motion="1">,<input id="l23" data-secondary-motion="2">, etc.

However, in today's predominantly Agile environment you have to take a more nuanced approach. You'll need to work closely with the other folks on the entire development team and agree on how best to identify elements for everyone.
When first working in such environments (in a QE automation role) I thought I could 'require' a unique id on every field or 'require' a data-qa-... attribute/value on all fields for automation. I have since found that this ends up being a huge battle about naming elements and identifier that wastes a LOT of time and energy and is likely to start stupid naming battles that suck up good energy and generate bad energy. I've since learned to "live with what's there" for the most part and work within the existing framework. Some examples:

• Ruby on Rails generates name= attributes for database related fields making them unique and removing the need to actually name them yourself as they just use the database column name field.
• Sometimes there isn't a unique ID but you can easily identify the element uniquely using other elements. For example, a locator of form might not be unique as there are multiple forms on the page and none have ID or CLASS or NAME and you don't want to fight the battle and time it takes to add them. Upon examining the whole page, however, one might find that an identifier of section.header form might do the job.
• In some cases, there is no element or combination of elements that will help and you will need to add them / ask the developers to add them. If you can prove that you can't uniquely identify the element for automation in a robust and sustainable way they should be amenable to adding them.
• In some case you may find that you can uniquely identify the elements but the locator is brittle. For example table tr tr td td td might find a certain piece of data in a table but the table is dynamically generated and changes with data. In these cases use a different strategy such as using another identifier in the 'chain' or adding unique ids to data. This is also why you don't just right-click on the element and copy its xpath from a browser. You'll end up with a brittle path many times.
• Use css locators when possible. In some cases using css will not work. For example if you need to find the table row that has an value of "tertiary" in the third column and then grab the value from the first column... consider using xpath to find the 'tertiary' row/column and then xpath relative addressing to get the value from the first cell (two 'back'). I rarely use xpath but this is one example of when I had to.

In addition to the issues of element selection on web pages you should also pay attention to:

• Workflows. Be sure you understand the full path and screens used by happy, sad and options workflows. Happy is the minimal 'get everything right' path. Sad is making errors and seeing the feedback and then Options is doing as many 'additional' things as possible on either the happy or sad flows.

• Devices and Browsers. Ask the developers (and the business folks) if they know which devices and browsers will be used / supported and which you should test in. They may need to think about this and research it. Also ask what they use if they test the UI at all. Look to avoid testing in a browser that developers don't check, and raising issues only to be told 'oh, we don't support that'. Make sure to base your browser usage statistics on YOUR traffic, not just stats from w3 schools etc. Make sure that if traffic is mostly mobile (increasing the case!) that developers aren't only looking at, say, Desktop Chrome when saying something works and is 'done'.

• The Goldilocks approach. You don't want to over specify the elements, e.g. body section table tr td div because you are now 'hard-coding' the structure of the web page which is very likely to change and 'break' your path. Similarly, you don't want to under-specify the elements. For example form might work today with only 1 form on the page but tomorrow a 'sign-in' form might be added to the top of every page, and this new form might break your path (in this case by finding the first form instead of the 2nd, the one you wanted). In this case you should consider locators such as form#primary_info or section.heading div.feedback form (assuming those specific id and class names exist on your actual web page). Don't try to anticipate too much ahead though - that's not agile - so try to get it just right.

• Use Page Objects as suggested by Neils and share this with the other team members. If you want the other developers to use the page object model you may need to introduce and champion it. I've had to do this in several organizations. If other developers look askance maybe relate to in-line javascript having similar issues with the solution being to extract that detail elsewhere).

• Existing tests. Ask the programmers to go over the (hopefully) existing unit and integration test to get a good sense of what are they testing. Ask them if they have any good ideas for bits of the UI that should be tested. Programmers have an inside view of the system and their different perspectives will often generate good test ideas.

Finally another reason to work within existing frameworks:
Some shops will absolutely refuse to allow you to add elements/attributes for automation to pages that end users use. Frequently the reason given is bandwidth. In reality, just given an image or two, the extra characters are usually less than 1% or even 0.1% of the total load, but despite this the directive is clear. One option here is to add a pre-processor that strips out these element/attributes for the live production site but leaves them there for test/staging for use by automation. I don't recommend this though as you are changing what the users gets from what you tested and it's not a good path to start down imho. At the end of the day this is why, although I've tried adding elements and special data-qa-... attributes it's simplest, easiest and quickest to work with existing elements whenever possible.

Summary:

Developers, designers, and automation engineers need to communicate and collaborate and come up with element/attribute identification methods that work for everyone.

Answer 2

Instead of automating after the code is done, try to automate during development together with the developers. This way you can solve any issues you run into together. Make it part of the definition of done of a feature.

So instead of planning ahead, try to fix issues as you run into them and get a common understanding of what is expected from each other. Else you might ask things from developers which you ain't gonna need.

Things I think that are important that need to be discussed are:

• Can we test in isolation
• What patterns do we implement in the test code (e.g. Page Object Pattern, Test Data Builder)
• Who fixes the test when one fails and what priority does this get over other work.

Answer 3

I feel your pain - I have to deal with the same problem.

Protractor (as suggested by Tam Minh) is one way to do that, but for the price: you have to write tests in JavaScript, which is for many (including me) too steep price to pay, because the rest of our development and testing is in Python.

We use locating elements by other methods: name, class, tag, text, etc. Often I will get a list of elements with the same name/class and loop over it to detect the one element I need by other means. Yes, it is a bit of hassle, but I prefer to deal with such a hassle than write test in JavaScript.

As any engineering task, you have restrictions, relations to other parts of the project, and trade-offs - so you deal with them in the most clever way you can.

Usually, developers add names/classes for me with little delay. If you need to locate something they don't work on, you can add names yourself and commit changes to the tree (following any review process your shop has).

Answer 4

AngularJS will generate some HTML, you should take a look on Protractor instead asking for "no dynamic ids"