go back to the blog

LiveBlogged! Automated Web Testing: Traps for the Unwary with Simon Stewart

  • 28/01/2013
  • no comments
  • Posted by EuroSTAR

Below is a live blog by Mauri Edo which was written during Simon Stewart’s webinar – ‘Automated Web Testing: Traps for the Unwary’ from Monday, 28th January.

Simon’s webinar is part of our Best of EuroSTAR 2012 Webinar Series Part 2. For more information about the rest of the webinars coming up this week check our website

Simon Stewart’s “Automated Web Testing: Traps for the Unwary” webinar review.

The first webinar of the Best of EuroSTAR Conference 2012 webinar week (part II) has begun with a follow-up of the elected Best Tutorial Award of the 2012 Conference edition: Simon Stewart’s “Automated Web Testing: Traps for the Unwary”. I am quite sure that you know who Simon is, but if you don’t, surely you know Selenium Webdriver, his direct creation as a member of the Selenium Project, a powerful and open source suite of tools to automate browser interactions.

Adding test automation to your project is a valuable milestone to reach, but once you’ve achieved that, it is likely that you will face stability and maintainability issues of those automated tests, of that code, in the end. Code stability and maintainability are well-known software development concerns and, in this tutorial, Simon has introduced several techniques to strengthen your test code, reducing the cost of maintaining it, here we go!
The webinar reviewed three basic things one has to know to achieve the stability and maintainability of the test code: how to find things, how to wait for things and how to keep the code clean:

How to find things: to automate tests, first of all you have to locate the elements you want to interact with. There are multiple possibilities available to find things, the commonest ones are the elements’ identifiers, the elements’ names, their CSS selectors and XPath locators.

The use of XPath is generally discouraged for several reasons: it turns out to be a complicated method to use; also there’s no need to use them by development teams, so developers won’t be aware of actions that change XPath location of elements, but these actions will difficult a lot the tests that are using this method; furthermore XPath is implemented differently amongst browsers, so you’ll have to be aware of those differences when using it. However, the use of XPath can be recommended in specific cases, for instance when needing to locate a parent element of the one we can track down, XPath can offer this feature easier than other methods available.

Simon defends that CSS locators are preferable for many reasons, for instance they are shared with Design and UX teams, so there are more people aware of them and they won’t change that easily. This makes tests based in CSS locators more maintainable than the ones based in unknown locators beyond test teams like XPath. Another plus of using CSS locators is that they are less brittle, being able to survive general DOM re-buildings.

To end with the “finding” section, Simon introduced to the audience to the capability of using JavaScript to locate elements that might change frequently of id, even of CSS locator. As long as those elements have some feature accessible via JavaScript that we can use to identify them across releases (for instance an accessibility class that remains untouched across the different releases) we can identify them with this method and interact with these elements afterwards.

How to wait for things: Some highly responsive web applications like Google Instant Search send each interaction to the server and return its response updating the results available in the same screen. These situations are a “waiting challenge” in terms of automation as our tests have to wait until the results are present to perform the further actions or validations needed. Other causes for delays pointed out in the webinar include local processing of JavaScript or the use of HTML5 webworkers features amongst others.

Delays in pages loading and in components’ availability require a good management of waiting situations in our tests. One way to handle this is to set implicit waiting in our tests, so when your tests fail to locate an element (because it is not available yet) they implicitly wait a certain amount of time until trying to interact with this element again.

With implicit waiting, we can avoid specifying pauses and waits explicitly in our test code; it gets simpler, but we will be waiting the same amount of time per not found element at first chance, so our tests’ execution will get slower. Explicit waits beat this last drawback, only waiting when it is needed. The presenter even suggested combining both methods to strengthen the test code, for instance setting an implicit waiting and then reducing it progressively to zero. The timeouts encountered in this operation will help us locate areas that require explicit waiting improvement actions.

How to keep your code clean: Simon declared himself a big fan of Object-oriented programming (OOP) and the DRY principle (Don’t Repeat Yourself), as they are great tools to keep the code clean and maintainable, reducing the need for code duplication. Page objects are the practical application of OOP and DRY to test code, serving as an interface to a page of the UI and concentrating all the methods regarding this page. Page Objects can be easily matched with the services offered to the users (for instance, the Login Page Object), becoming the only place with a deep knowledge of the structure of the page covered and simplifying test writing as well, as there is a clean separation between the code of the specific page and the test code that uses the Page Object interface available.

Page objects can become composed, even mutating into Component objects (for instance, the Navigation Bar Component Object). This way, if a component is reused in several parts of the application, implying different pages (like a search bar available in the home page and then in other specific pages of the application), there’s no need to have different Page Objects with search bar features but a single Search Bar Component Object to feed them all.

To end with this section and the webinar itself, Simon also offered alternatives to achieve simplification beyond OOP and Page Objects like using narrative-based frameworks, BDD frameworks like Cucumber or even custom Domain Specific Languages.

That’s it! A fantastic webinar that revealed how a deep knowledge of the features of the tools we are using to automate tests and the languages they are based in can help us advance in the milestone of having a powerful, stable and maintainable automation features in our testing projects. Thanks Simon!


mauri_edo1Mauri Edo is a self-made testing professional currently working as a QA Manager at Netquest, a firm specialised in on-line market research services, from Barcelona to the world. Always ready to discover new things, Mauri is a huge defender of continuous learning, knowledge sharing and testing conversations. You can find him on Twitter as @Mauri_Edo and blogging at (Spanish) and at the Software Testing Club (English)

Blog post by

go back to the blog


Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery