At Deacom, our manual QA team spends a fair amount of time executing click-by-click test scripts, all of which can take an hour or more to complete. Realizing the tremendous cost-cutting opportunities that can be gained through automation, Deacom set its sights on TestProject 🌟
I was charged with the task of automating some of our biggest manual tests so that the QA team can focus the majority of its time and energy on testing new enhancements and help facilitate customer projects.
The biggest challenge – locating UI elements
Automating Deacom tests proved to be a formidable challenge, considering the sheer number of elements and the fact that the majority of these elements have dynamic XPaths.
For someone who didn’t want to spend hours learning how to navigate and manipulate the DOM, TestProject’s ability to locate elements according to static attributes such as text, title, and class has helped me avoid the instability inherent to dynamic XPaths, which was a huge hurdle of mine.
TestProject also grants users the ability to quickly set up element location by attributes of their choosing, such as datacontrolsource- a static attribute that I used heavily when automating Deacom’s web application 🌐
Stability is absolutely crucial in building robust automated tests, and not all of the elements in Deacom were able to be located by static attributes such as text, title, class, or datacontrolsource.
But, between the dozens of hours I’ve worked with TestProject, their friendly support team, their FAQ system, and, as always, StackExchange, I was able to adopt some tips and tricks regarding XPath manipulation. Those that helped me avoid the instability that’s inherent to many of Deacom’s element paths.
Automating tests for multiple modals and tabs
For example, Deacom contains plenty of modal windows that can appear and overlay other modal windows. Some of these modal windows contain the same element with the same data control source, text value, or label.
But, by wrapping the element path in parentheses and appending ‘[last()]’, as TestProject makes very easy to do, I was able to consistently pull down the element that was in the foreground while ignoring unnecessary elements that lay behind it.
In a similar way, if there were two tabs open in our web application and each tab contained a grid row with the same XPath, TestProject allowed me to focus on whichever tab I preferred with a simple edit to the element path.
As another example, many of the grid rows in Deacom can be located with the following XPath: //div[3]/div[3]/div[3]//tr[2]. However, if you have two tabs open and each of the tabs contains a grid row with that XPath, simply wrapping the XPath in parentheses and appending an index allows you to choose the correct element 100% of the time, which is pivotal for test stability.
If I want the first grid row from tab 2, I use the following XPath: //div[3]/div[3]/div[3]//tr[2])[2]. And if I want the first grid row from tab 1, I use this XPath: //div[3]/div[3]/div[3]//tr[2])[1]. These are just a couple of simple examples highlighting how easy-to-use and flexible TestProject is, even for applications with dynamically changing elements ✅
Conclusions
Overall, TestProject has been an invaluable resource for cutting manual testing time at Deacom. Between its ability to handle a variety of actions such as drag and drop, color capturing, screenshot comparisons, date and string manipulation, effortless parameterization, and so much more, it has proved a tremendous resource for freeing our manual testing team to other projects. It’s a miracle that TestProjects is free! 🤩