Webdriver challenges working in an agile project – Part 2

Challenge 4 – Agile V Fragile

One of the biggest issues with test automation is tests being very fragile and constantly breaking. To minimise this, ensure that you have a robust framework in place. A page object model is quite popular amongst automation testers allowing all objects for a particular page to be held in one class allowing them to be more easily maintained when changes are made to an element.

Whatever framework you choose, make sure that you don’t duplicate your code, ensure you don’t have to make changes in more than one place and constantly refactor your code.

Create a sprint task each sprint which factors in the time it will take you to refactor and maintain your tests.

Also, be proactive rather than reactive by planning upfront with your developers to make sure that element ids are always used where possible and the UI elements aren’t constantly changing for no reason.


Challenge 5 – Tick Browser not Cross Browser


One of the benefits of using Webdriver is that you can automate across different browsers that are supported. However often you may come across a test that only breaks in for example IE.

Concentrate on getting all the automation pack working consistently in the most important browser to your project first rather than making each test work in every browser. Once you have a working set in your default browser, only then should you try to get the tests working in other browsers. This will ensure you don’t beat your head against a brick wall spending days on a test that doesn’t work in a browser meaning that you have failed to complete your automation task for that sprint. In a worst case scenario, a quirk in a particular browser sometimes mean that a particular automation test needs to be removed from the set of tests to be run in that browser.


Challenge 6 – Gherkin smells bad


In a BDD project, there will be Gherkin acceptance tests written in the Given, When, Then format. This is a very powerful framework allowing both testers and anyone from the business to write such tests in a truly agile way. The problem arises however when the same or similar Gherkin statements are written differently resulting in inconsistently looking scenarios but also more importantly duplicating test methods and therefore effort.

Again this comes down to design and planning. To avoid this, have a workshop with all the testers and the business that will be writing these acceptance tests so that everyone is clear with the format and consistency is maintained.