Taking testing Back to the Future
In the 1985 box-office hit Back to The Future, Marty McFly is sent back in time to 1955. Marty and his mad scientist friend Doc Brown begin theorizing and testing ways to get Marty back to the future. In the film, Doc and Marty didn’t get to do much testing: in fact, they were the ultimate example of pushing to production with hope, wishing for lightning to strike.
In the world of software, and particularly SAP, many of us have been like Marty and Doc at some point. Maybe even on a more regular basis than we’d like. Testing helps us to make sure that the lightning strikes when it’s supposed to, but it’s hard and it’s slow. Automated testing has long been lauded as the solution for frustrated subject matter experts to avoid the monotony of manual testing, and for industry to avoid this expensive and non-value add activity. The reality is a bit less ideal. Testing is tied down by poor tooling that’s expensive to create, maintain and drive to value for the organization. What if we could take testing Back to the Future, and make the automation promise real?
So, what is the issue? The problem with many automation solutions isn’t the ability to automate test execution. In fact, some do this with aplomb, employing sophisticated scripting, object-action, and user interface automation technology. The problem comes with creating and maintaining the script library: the effort to create the initial library is greater than a single pass of testing, and it requires special skills. Success with today’s automation tooling is an investment, and only pays a return after significant commitment.
Put simply, much of the effort behind success with today’s test automation is stuck in the past. Business user interviews, process documentation, script recording and authoring, test data management and library upkeep are all manual activities. And they are technologically sophisticated tasks: the most successful organizations with automation as we know it today are businesses with significant software development experience. They have the human capital to design and take advantage of the technical nature of user interface automation.
That leaves many corporate users in a pinch. Surely, there must be a simple way to ensure updates to SAP don’t break existing business practice? Using traditional UI automation, this regression testing would require a comprehensive library that’s difficult to create, and expensive to maintain. And, often, what testing it does provide is far from comprehensive, leaving customers with a “push and hope” reality about production change.
The missing element is automation for the whole SAP regression cycle, including the creation of the tests themselves. Until now such a comprehensive approach has been impossible, but that’s all changed thanks to a new technique to automate regression testing called Robotic Test Automation (RTA). With RTA, the tests, data and automation are created automatically. That eliminates the most common barriers to success with testing automation for SAP and provides users of the technology the ability to comprehensively test the current state of business practice against proposed changes in the system, reducing risk of change. Perhaps best of all - though no doubt it depends on your point of view - RTA frees business users from the shackles of repetitive, time-consuming involvement in regression testing.
The future is automation… and automation of all aspects of the regression testing lifecycle. Take regression testing back there for your next production update of SAP.
Find out more about RTA and Testimony, the product that makes it possible, here.
