I am evaluating low-code/no-code GUI automation tools for Software Testing, and it has been a fun experience. I recently had an interesting conversation with a support person of a tool, and our discussion centered around why there are multiple paths of reaching an element in the GUI.
“The answer is the DOM“, he explained, “Even if you don’t give the exact text, that would help locate the element in the GUI, the DOM would still have a map to trace it down”, he added.
“Wait! I have a field that clearly should say the text that’s displayed in the GUI, and I want to check that”, I protested, “but you are saying I can specify ANY text and your tool will be able to locate that element?” I asked, bewildered.
“Yes Sir, that’s because of the DOM”, he said.
And that, folks, was my first rub with GUI automation headaches. I kind of figured how it could lead to some flaky tests, but I never wanted to argue with him at that point. I let it go. But one of these days, I am going to get to the bottom of it and challenge him. Or his tool. Or the whole GUI automation business itself!
While I personally feel that API is preferable wherever it’s possible over GUI, GUI cannot be avoided in some portions of the solution, so we got to handle the GUI automation, like it or not. We all expect a tool that would, in a wave of a magic wand, generate the automation scripts for our GUI, it has not been practically available so far, so we got to live with what’s available!
