What to ask programmers before automating with Selenium



  • 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.



  • 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 ,, 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2