The pace of innovation and disruption is accelerating.
So says Barry Ritholtz in an article entitled “The world is about to change even faster”
He’s right. Technology changes too quickly for any one company to stay on top of it. New software is released so regularly that it is already out of date by the time it is launched – consider the frequency of SAP or even Microsoft updates; keeping on top of these poses a real headache to most IT departments.
We’ve got to a state where traditional testing processes and tools are too cumbersome, and development is pulling away. Testing becomes the bottleneck. We don’t need test assets which have cost companies thousands of dollars and man-hours to develop. What the business needs now are test assets that are quick and easy to develop, that can be reused or adapted easily or can be discarded without a second thought.
“Think about your own test assets. Can you even estimate the cost in time and effort in building them? How constricted are you by that investment?”
Now it would be foolish to dispose of the entire test automation concept purely based on what came before. We need to recalibrate our expectations and remind ourselves of excellent potential benefits from test automation if only the capabilities were delivered in a form usable by all.
The ability of any automation technology to adapt to changes in the underlying application will always have some limitations. Is it reasonable to expect a test script created for a legacy mainframe application to still be valid on the replacement responsive web architecture? Can you expect the test scripts created for the English version of your website to be applicable to the newly developed Japanese version?
By freeing automation from the burden of a test script based on code, we can begin to imagine a solution that could be used by subject matter experts and not limited to frustrated developers, a solution that could adapt to changes in the application under test, an intelligent solution that inherently understood the application under test, removing the need to develop logic in addition to the validation itself.
The exciting thing is that modern automation goes a surprisingly long way towards addressing these needs. But do not let that optimistic outlook hide the core issue – at some point, the application, environment or business will change in such a fundamental way that the existing test assets have little or no value.
If that loss represents an investment in intellectual property, resource, and time at a level so large that there is no appetite to redevelop those assets for the version of the application, then automation will have failed. Thus we arrive at the acid test – if it is deemed easier to return to a manual test approach, then automation has failed and deserves to be thrown away.
