For many it’s a no brainer to bring automation into the testing process but something that can ruin your approach is not building maintainability into your scripts.  I started working in QA automation 7 years ago using the Selenium IDE, which is a record and playback tool, and it was groundbreaking at the time.  All of a sudden a job that was done mostly in the manual fashion could be automated easily?  But soon the community began to learn the caveats of this approach.  Its been awesome to evolve with the automation movement and see how we have shared our experiences regarding pitfalls to avoid.   Every day I think about how we can improve our automation test framework and my team's absolute nemesis is brittle scripts.

A brittle test can just be a test that fails intermittently and it’s unclear why.  It could be a test that is difficult to update, or due to a page that is commonly updated so suddenly the path to an element changes.  If you haven’t thought through these kind of scenarios when approaching your automation project, you will end up wasting much of your time managing out these problem scripts instead of concentrating on growth.

One basic problem that can be avoided is thinking of locators in your scripts as variables.  Let's say you have a button on a page that you utilize across multiple scripts.  If the locator for that button changes, suddenly all of those tests fail and you must update it in every test script.  There are two things to be aware of to avoid this problem: brittle locators and duplication in scripts.

For brittle locators the first piece of advice I have is to avoid absolute paths.  If you utilized the Selenium IDE that is what you would get.  Instead start with the element ID and work backwards. It is easy to find suggestions on how to approach locating elements in the UI so I won't rewrite a full rant on the best methodology here but do your research and get your team on board.

You can be smart about your locators and still run into problems with brittleness due to duplication. Say you have 10 different tests that reference the same object on a page (create new field button for instance) and you have been smart about the locator utilized.  Still the locator changes and suddenly we are updating 10 different tests.  This maintenance headache is a waste of time that can be avoided by modularization. We utilize the 'Page Object' pattern to avoid this problem, so when clicking on that ‘save’ button on the page used in multiple test scripts, we reference that action once.  Again I won't go into specifics on the page object pattern for QA automation since there is plenty of documentation out there already.  I highly recommend evaluating this approach for your own automation projects.

Duplication is not limited to locators, it also can be the workflow for an action that is common in tests.   This is where the Page Object pattern helps us to follow the ‘DRY’ (Don’t Repeat Yourself) Principle.  With the Page Object approach, we consolidate the code interacting with a UI element.  Instead you now have methods for what a user can do with exposed elements on a page.  Now N test scripts can call a method to access the edit settings page for a user.  This leads to less duplication as well as more readable test scripts as the details of how we access this page are executed via a method the script calls.

Automation can make a world of difference in the ability to verify the quality of your product but it can also be a huge pain if you don’t think of the long term approach and effect of taking short cuts.  Not everything should be automated.  Take a step back and look at your framework.  Are you encouraging your team to just pump out tests to show a boost in your automation or create a highly efficient and low maintenance approach that your organization can use long term for stability in your product?  We all want things done as quickly as possible but it will cost more in the long run if  reducing brittleness is not something your QA team takes into account.