Maintenance of test scripts can be the hardest part of test automation!
Have you ever struggled with –
- Flaky automation scripts that fail too often for no reason
- Unable to start or continue test automation because your elements keep changing with redesign. Often leaving automation lagging behind.
- Finding it hard to add new steps in existing scripts – it takes forever to find, debug and write new code!
- Hunting for the root cause of each failure and trying to correct the false negatives that happen due to small UI changes.
- In Agile projects, each sprint sees the application evolve and change – you struggle with updating your scripts for every change!
If you are a tester working on test automation, you surely have faced these challenges some time in your career.
The reality is test automation scripts will need changes based on the type of change you have in your application.
Maintaining test scripts often takes more time and effort than actual scripting.
Why do these changes happen?
Let us understand where do these changes happen?
Changes in test scripts can be attributed to one of the following-
Changes in Business Flow
Changes in Business Flow mean the flow of use case has changed. It may mean a change in how the user experiences the application, performs the steps, or sees the screens. Business flow is the least likely to change after a few sprints as the application stabilizes. But when it does change, it garners a much bigger effort to make the relevant changes as the entire flow of our test automation needs changing.
Changes in Implementation / Steps
When the flow remains the same but how the action is performed or the sequence within changes due to change in the application.
Let us say that in the previous sprint- you used to click on a link to access the product page and then click view image to see its images. But now it is redesigned such that you click on a Product button to view its details and the images are pre-loaded and you just hover over them to view.
Changes in Elements/Screens
These are the most common changes that happen. As we incrementally build the application, the element accessors may change due to change in attributes, location, or screens where they exist. Since we make use of the element accessors in our test scripts, these changes impact the execution and may cause false failures.
Anyone who has ever written a single automation script has faced the error
“Element Not found”
Element accessors are prone to most changes and when scripts fail due to reasons relating to element not found or not recognized, you might need to go back and edit the element’s accessor because of changed xPath or attributes.
Robust scripting needs you to separate the code from your element accessors.
Understanding these common causes of frequent maintenance needed for their test scripts, testers need a framework and a tool that can help make this process easier and more intuitive.
The solution using Sahi Pro v9.0
Sahi Pro’s Business Driven Test Automation allows you to set up a layered framework such that you can control, edit, and maintain your scripts for any possible changes easily.
The effort spent by testers in maintaining their scripts is drastically reduced with Business-Driven Test Automation and they can now spend more time thinking creatively about new test scenarios for their business.
Sahi Pro brings you an intuitive UI and a tester-friendly experience to help you edit and manage your scripts easily!
By following intuitive operations on the UI, you will be able to edit and manage your test scripts for any changes with minimal effort and no coding.
- Changes at the Business Level
> Using Scenario file in BDTA Without having to change anything else or redoing any of the past effort, you can easily add or edit a step in your business scenario!
- Creating a separate Accessor Repository
> Sahi Pro’s Accessor Repository (AR) functionality allows you to create accessor repositories automatically either during the recording or thereafter using a single click.
> In a single click an AR file gets created saving all the elements used or touched upon within your script.
- Changes at the Implementation Level
> Sahi Pro’s layered architecture of test automation helps you locate and make these changes very easily.
> Use breakpoints, debug scripts, update function libraries as needed. - Editing and Updating Accessors and Keys
> You can explore your options to find a better accessor using the Sahi Pro Controller and using Relational Accessors like _near, _in, _rightOf, _leftOf, _under and _above to locate your element in relation to other elements on the screen.
> You can update your accessor repository with the new accessor for a certain element against its key directly in the csv file.
> You can see the changes updated in our AR file automatically.
Want to learn how to do it step-by-step?
Watch this video to learn how to handle any changes in your scripts and edit and maintain your scripts it in few easy steps https://www.youtube.com/watch?v=dq_nXR88O9A
An intuitive and simple approach
Sahi Pro scripts are easy to edit and maintain.
All the changes described above require a few minutes of effort, can be performed using intuitive options on the UI with a few clicks. And there is no Rework or Edits required for existing script unnecessarily.
Here is a brief on how much time and effort you would spend on making a change in Sahi Pro scripts-
With Sahi Pro, you can leave the drudgery to your trusted tool that is your test automation partner, while you work on designing the best and most meaningful tests for your business. Testers spend more time on the creative aspects on testing rather than updating and maintaining old test scripts!
Isn’t it super easy and intuitive!
Are you excited to give it a try?
Get Started Now
Complete Playlist to take you end-to-end through BDTA concept and usage.
Learn more about Sahi Pro v9.0.
Download a Free trial version of Sahi Pro to give it a try.
