We all agree that test automation is key to delivery of quality applications under whatever development and delivery regime we chose to employ. This is more critical in continuous delivery environments, so why do we continue to create applications that are so difficult to automate? In both past and recent experience, I have found automation engineers working tirelessly to overcome challenges presented by applications that cannot be easily automated. This leads to complex and fragile automation code, with engineers often having to resort to coordinate based techniques and OCR with its inherent frailty.
What makes an automatable application?
The primary concern in making an application automatable is creating an interface that can be interacted with by other software. So how can we benchmark what constitutes an automatable interface? The OS providers have built in frameworks that help us do just this.
Windows provides a great example of this with its UI Automation (UIA) framework. Building upon Microsoft Active Accessibility (MSAA) in earlier versions of windows it provides a framework for building accessible applications and facilitates robust test automation. It is the framework that Coded UI, TestStack White and other automation tools are built on. A good place to start is to benchmark our applications conformity to accessibility frameworks and it is a safe bet they will be automatable.
Choosing third party control sets
Let’s face it, with the vanilla .NET control set Microsoft created a utopia for automation engineers. They created a set of controls that fully supported UIA and presented robust and consistent control patterns with an object based interface that automation code could properly interact with. The same cannot always be said for third party control providers with both heroes and villains existing in this space.
When we chose the third party control sets for our product, one of the key selection criteria was conformity to UIA. By inference if the controls supported UIA, then they presented an interface that could be worked with from a test automation tools perspective. We now have a robust regression pack of UI tests built using our own product alongside Coded UI. I wonder how many other automation tool providers eat their own dog food?
“Automatable” as a development requirement
My last word on this is making the provision of automatable interfaces a development requirement. We should agree that, as important as it is for an application to be functional, usable and optimised for performance it should also be Automatable. Surely this makes sense?
And here is the clincher, automation engineers should be able to raise defects against that requirement. If the application presents an interface that is not suitable for automation then a defect should be raised, and it should be fixed.