5 Ways to Minimize QA Automation maintenance efforts with ongoing product changes

Amir Najjar

Automation Developers are often too familiar with what they consider, the annoying maintenance effort, which needs to be done on a regular basis, especially in a technological era where everything moves in the fast lane; However, there are always a bunch of things that can be done in order to avoid day to day maintenance and the struggle of keeping up with a changing product with more than 5 releases a day.

I took the liberty to write some tips in order to prevent annoying day to day maintenance:

Keep the web developers close to the Automation Developers:

Let your QA Automation Developers stay in the loop and be an integral part of the R&D. Have them know about product changes beforehand. Make them participate in iteration kickoffs, retrospectives and dailies. This way, everyone will stay up to date with what is going on with the product’s lifecycle, what is going to change, and what will keep functioning the same way it used to function.

5 Ways to Minimize QA Automation maintenance efforts with ongoing product changes

Mentor Web Developers:

Put some guidelines for web developers, tell them not to make unnecessary changes, such as “classNames, tagNames, IDs …etc.” just because there was a typo in the locator or for any unnecessary reason! Nobody cares about typos in locators, and fixing these typos, it will only affect automation locators and lead to unexpected maintenance. When a certain HTML change has to be made, the web developers have to keep in touch with Automation developers and let them know about changes before they even make them and this way, “Element not Found Exceptions” will be completely bypassed.

Build smart locators:

Have Automation developers build their locators in a smart way, where locators shouldn’t be related to WebElements’ locations, if you have an ID, then it should be a unique locator and should be used first thing. ClassNames could also be unique sometimes, but not always, so when you use ClassNames, validate they are unique, if they aren’t, then base your locator on private methods which will return the correct WebElement. Sections usually have unique wrappers, so you can start from returning the wrapper or what I like to call “anchor” and from there; look for the ClassName you need to return.

Always use POM (Page object models):

Always use POMs! No matter how small or big it might be, use it! Use it to implement a page, a part of a page or even a small popup.

The more and the smaller POMs that you have, the less changes it will require for you to make if anything changes.

When you use POMs, it will reduce code duplicates and enforce code reusability, making your code agile and easier to maintain in case of changes.

Write Generic POMs:

Generics play a big role in the design of your Page Object Models, try to have your POMs work in various places of your product, just make sure not to overdo it.

Let’s take a table for example; if you have a table object which can be found in many places on the site, it’s a bad practice to duplicate this object, and have a different one for each page; why? Because if any of the locators gets changed on the site, you will only need to modify your code in one place rather than go over a bunch of table objects and modify them all.

Now I know that this table can differ in terms of different header names, the number of rows and even the number of columns.

But if you build your table POM component in a way, where the constructor initializes the header names, and maps them to their corresponding column index, you will make your table generic and thus, reuse it in many places of the site.

Amir Najjar is QA Automation Team Leader at Galil Software.