Testers worldwide are faced with similar issues and challenges in their test automation journey. The most common issues teams face pertaining to test automation are that scripts are brittle, fail too often and require a lot of maintenance.
This mostly happens because we are scripting everything at the same level, and when something changes at business level or at a UI level or at the data level, we end up going to the same script every time and trying to alter it.
So, what does it take to be in sync and achieve maintainable test automation?
- Less Work to be Done: We need to reduce time of creation and try to offload it to machine instead of manual scripting. This is where a robust tool with good recorder, object spy and authoring capabilities can help.
- More Hands to Help: We need to focus on getting more stakeholders and people involved and participate in the process, by contributing in some way to the overall process of test automation.
We can make this happen by understanding the different layers of test automation and how to separate them.
Maintainable test automation: Let’s consider the case of a user transferring money to another person and see how these layers help.
Layer 1: Business Layer
- This layer expresses business intent.
- It is agnostic of the UI or the web application itself, testing tool and interaction code, for example: Create User, Approve User, Login User etc.
- This layer will change only if business logic itself changes. So, it survives across UI implementations (web or mobile or desktop), and survives architectural changes.
- In this layer we can talk in the language of the business, without assuming anything about the UI, tool or code.
In Sahi Pro, this layer is implemented as Scenario files. This is a csv file which can be edited in our Editor or via MS Excel. A sample scenario looks like this:
Notice how the business layer does not assume anything about the user interface. It does not matter if this is on a web application or on a mobile app.
Also, each of the steps in this business flow will correspond to functions or methods implemented separately.
Layer 2: Implementation Layer
This layer implements the business keywords specified in the previous layer
- Understands interactions between different actions performed on UI
- Library file with implementation of keywords used in Business Layer
- Will change if interaction flow changes
Note the name of the method corresponds to the relevant step in the scenario file, the number of arguments and their values are also picked from the provided scenario, while the actual code for the step is implemented inside the method.
Layer 3: Accessor Repository Layer
This is the layer where we store every element’s locator and accessors.
- This is the Central repository of all elements in the automation code
- This changes when a particular element changes in the application UI (for example, due to HTML/Javascript changes in web interfaces)
As you see now, the business layer will be where you will define the flows and actions for every use case. This is high level and mostly worded in natural language. So, eventually your business team as well as manual testers will be able to write the scenario files easily.
The implementation layer is where you take each action and define the methods containing steps to perform that action. This is easily doable using any automation tool. With Sahi Pro, you can use record and playback as well as write your own using simple java script. These functions are stored in library files. These will change only if the flow or sequence of steps changes. These functions are not hard coded with your object ids, so they will not change even if an object’s locator changes. The locators are all in the Accessor Repository layer.
The Object locators are saved in Accessor Repository (AR) files.
In Sahi Pro, you can create an AR automatically as you record your script, and you can also have a single AR for multiple scenarios and scripts. This AR is the place you need to go and edit the object locator if anything changes.
Conclusion
- Automation code is most useful when there is a lot of change planned in your application
- Acts as a safety net and guideline
- Automation code should not be thrown away when application technology changes
- Building the right layers and strictly following them helps in minimal maintenance efforts and long-lived useful automation scripts
Find out more about maintainable test automation at the EuroSTAR Conference, Nov 11-15. Book your tickets now!
——————————————————————————————–
Author: Nishi Grover Garg – Product Evangelist and Head of Trainings, Sahi Pro
Nishi is a corporate trainer, an agile enthusiast and a keen tester at heart! With 11+ years of industry experience in Agile environment, she has worked in various roles as a hands-on tester, automation developer, a freelance consulting trainer and currently works with Sahi Pro as the Evangelist and Trainings Head. Nishi is passionate about training, organizing testing community events and meetups, and has trained hundreds of professionals and teams on agile, test automation, QA bootcamps and DevOps courses.
Nishi is also a writer on technical topics of interest in the industry and has numerous articles published at numerous popular forums and her own blog testwithnishi.com where she writes about the latest topics in Agile and Testing domains. Connect with her at @testwithnishi