Why is Object Identification GUI Utility in Test Automation Unnecessary?
Don’t waste time and money on a tool that slows you down and generates inferior test steps.
This article is one of the “Be aware of Fake Test Automation/DevOps Engineers” series.
In Automated End-to-End Testing, many so-called ‘cool’ features (as below) are either counter-productive or unnecessary:
Record-n-Playback (coming soon)
Object Identification Utility
Test execution recording, e.g. video/screenshots
In this article, I will talk about “Object Identification” (some tool vendors call it ‘Object Map’). I have been developing/maintaining thousands of automated UI (web) tests since 2005, and have never used “Object Identification” utilities(except reviewing).
Test automation vendors often highlight the Object Identification utility as a helpful tool for creating automated tests with ease. In reality, it is unnecessary. As a matter of fact, it will be far better without it.
Object Identification utility, in web app testing, shows the HTML (the source of the web page) DOM tree in a graphic form (as in the above screenshot). According to the vendors, testers can easily select the ‘identified object’ to use in test scripts. Sounds right? No, it is not.
Object Identification generates inferior test steps
When testers use Object Identification, they are selecting the identified controls (in a graphic form). In other words, they are somewhat limited to that extra layer (on top of the page source). Naturally, a tester will select whatever is conveniently shown there, which will inevitably lead to poor-quality test scripts.
Let’s look at an example: entering text in the textbox on this page (shown in HTML).
<div id="user-email">
<label for="name">Name:</label>
<input type="text" name="name-2fe28a53-b055-456a-bbde-276def2ecb3a" value=""/>
</div>The tester moves the mouse to the input control in the Object Identification window, clicks and expands, and then selects the name attribute. The generated test step might look like this:
driver.find_element(:name, "name-2fe28a53-b055-456a-bbde-276def2ecb3a").send_keys("Foo")It worked. However, it is wrong! The name attribute contains a GUID, which will change the next time.
It is better (and easier, in my opinion) to create a more reliable test step like the ones below.
driver.find_element(:xpath, "//div[@id='user-name']/input[@type='text']").send_keys("Foo")or
driver.find_element(:xpath, "//label[@for='name']/../input[@type='text']").send_keys("Foo")With the help of basic XPath knowledge and general editing features such as Snippets in TestWise, this can be done quickly.
Object Identification is limited when testing dynamic operations
With more and more web apps being dynamic (use of JavaScript /AJAX), the use of object identification is increasingly limited. For some operations, it is simply not feasible or results in the test step executions are unreliable.
Some might argue that it is not true as the full-page source can still be viewed in the Object Identification window. In that case, why do you want to spend thousands of dollars on this tool?
Object Identification generates unmaintainable tests
Object Identification generates inferior test steps, and inferior test steps will lead to unmaintainable test scripts. However, let’s face it: good test steps can lead to unmaintainable test scripts as well. For example, the below Selenium test step is OK. Though it runs well, I would not be able to maintain 200 test scripts consisting of many test steps like the one below.
driver.find_element(:xpath, "//div[@id='user-name']/input[@type='text']").send_keys("Foo")The solution is to refactor them into Page Object Model (POM, see Maintainable Automated Test Design) by using test refactorings.
login_page = LoginPage.new(driver)
login_page.enter_user_name("Foo")Some might argue: “we could refactor the Object-Identified test steps into POM as well”. Yes, but it is very unlikely.
The tool (does Object Identification) won’t have good support for test refactorings, as refactorings support is on text-based code/scripts only.
The testers, who went on the Object Identification path, would be very unlikely to spend extract efforts on refining/stabilising/refactoring test scripts (a lot harder than test creation). For a start, they are probably not sure what test scripts would come out from the tool. Typically, those testers thought the job was done after running OK once.
By the way, “refactoring support” is listed as the top feature of ‘Next-Gen Functional Testing Tool’:
We are lacking integrated development environments that facilitate things like: refactoring test elements, command completion, incremental syntax validation (based on the domain specific test language), keyboard navigation into the supporting framework code, debugging, etc.
- The Agile Alliance’s workshop to envison the next-generation of functional testing tools
Object Identification is inefficient
Let me share a true story here. There was once a UFT Developer video on a website to show how to create a simple automated test in UFT Developer. I gave it a laugh as it was so inefficient. At that time, a junior engineer (of UFT, not a UFT Developer, but willing to learn Selenium) sat with me. I told her that I would use 1/3 of the time to create the same test in a much more logical way. I added: “Besides that, you will be the one to complete it. Just follow my instructions (on typing)”, and she did.
The so-called “Object Identification increases efficiency” is wrong. For people who don’t know test automation at all, it might help them create a few unmaintainable tests. What’s the use then? It is even worse than no test automation.
In a real test automation engineer’s eyes, object identification is counter-productive. It is more efficient and fun with raw scripting in a good Testing IDE. This is actually easier to understand, keyword typing (especially with assistance from Testing IDE) is much quicker than moving the mouse to click, expand, and select. Check out my article: “Step by Step showing how to learn to write raw Selenium WebDriver test scripts in minutes” with video.
Don’t just take my word for it, you will find out that scripting automated tests in Testing IDEs or Programming Editors have always been the case in top companies. Check out this article: Recommend a Great CI Presentation: “Continuous Integration at Facebook”.
If not using Object Identification, how do we identify controls?
Easy, use Chrome’s (actually all browsers nowadays) inspection tool. It is easier than you thought. I have proved this to many manual testers who attended my training.
See it in action in this article: “Step by Step showing how to learn to write raw Selenium WebDriver test scripts in minutes”.
Why do tool vendors try to sell the evil stuff?
Wise readers might get it after my explanation and wonder “Why these bad practices were torched as helpful?” The short answer: Money. In my opinion, these tool vendors never understood test automation anyway, and never did one single sizeable real test automation successfully.
Taking the featured MicroFocus’ UFT Developer screenshot as an example: there are three components:
Java IDE (with a test file opened: SeleniumTest.java)
It looks like Eclipse, a free and no-longer popular Java Coding IDE. I emphasized ‘Coding’ here as it is not designed for testers.
The test script is pure Selenium WebDriver with Java binding.Embedded Browser
Strictly speaking, we should always use a real Chrome browser (the same as the user’s). The whole purpose for vendors to embed one browser instance (not sure of its underlying technology or version. This also exhibits another potential problem) is to support Object Identification.Object Identification Window
In other words, UFT Developer is more like a plugin of a free Java IDE. The selling part is only ‘Object Identification’ and record-n-playback (this is evil too, and has been covered in another article). Without these two unnecessary components, how can they charge customers ~$10,000 per license?
I am not picking on Micro Focus’s tool, there are similar ones such as IBM Rational Functional Tester (RFT). I used and did a review of RFT at a government department (probably only the Government sectors will purchase these expensive useless tools). RFT was so unreliable and slow (check out this ridiculous RFT bug I encountered, probably still not fixed). Frustrated, I used RFT as Eclipse (RFT in fact a rebranded Eclipse Java IDE with an automation plugin) to create Selenium WebDriver tests in Java. It was much better. However, the management stopped doing that. It was very embarrassing to pay for a $11,000 license for a free Eclipse IDE to use Selenium WebDriver.
The solution is far simpler (and cheaper): use a good testing IDE to help with raw Selenium WebDriver test scripts. If you are interested in my approach, check out the AgileWay Test Automation Formula. You may get 3x or more productivity on creating no-vendor-locking, high-quality and maintainable Selenium WebDriver tests quickly, without paying a cent.