Achieve Comprehensive Regression Testing in SAP without Writing Scripts
‘Test scripts’. A phrase that can strike fear into the hearts of the most intrepid team of developers, QA experts and project managers as they try to deliver changes into an SAP system on time and under budget.
OK, perhaps not so much ‘fear’ as a disheartening sense of resignation. The fact is, test scripts are an intrinsic part of pretty much all the traditional approaches to SAP regression testing. After all, someone has to define what needs to be tested before a test can be run, right? But nobody really wants to be the one who has to make them.
This is especially true for SAP regression testing, where much of what you’re trying to test is ultimately related to business processes and the related outcomes. The best of you will have those processes mapped somehow, but to what level? I’m willing to bet not many process maps define which screen should appear, which button should be pressed, which value should be entered, etc, at every step. So, you need some scripts to make sure your changes aren’t going to break things.
The problem is – and I don’t suppose I’m revealing any secrets here – regression test scripts can be hard to create. Not only do you need technical input from the SAP team, you need to get the functional teams involved since they’re the ones who understand real processes and can validate what the outcomes should be. And those people already have day jobs.
On top of that, if you’ve ‘simplified’ your testing process by using some sort of traditional tooling you might need developers to write the code needed for your automated test execution.
So, yeah, those scripts are hard to make.
But that’s not the worst of it. You’re going to need a lot of them. A LOT. SAP often touches every facet of an enterprise, from front office to back, connecting with multiple SAP and non-SAP external systems, so to make changes with a sufficient level of confidence you’re going to have to test a lot of stuff. I spoke to one of our customers recently who said they were reasonably happy with their regression test coverage. Great. How many scripts? Oh, only around 12,000!
I’m pretty sure you’ve figured out the equation here. Taking a traditional approach to regression testing, and therefore relying on test scripts, means
Confidence = (SAP + functional + technical team input) X (LOTS of processes)
If we do a bit of pseudo-math and substitute time for people, that means
Confidence = A long lead time
Substitute time for money (since it’s not news that the two are often equivalent) and we get
Confidence = A lot of money
There’s no getting away from it. When you change your SAP systems you need to be confident that you’re not introducing unexpected negative impact on your business. Until now you’ve needed to regression test using test scripts. Which makes your project slow, and costs a huge amount. To put it very simply, when using traditional regression test methods
Keeping your business safe = A lot of time + A lot of money
Oh, and wait. The maintenance. Did I mention the maintenance? Who wants to put their hand up for the job of analyzing which of those 12,000 scripts are impacted by change X and need to be updated? Not me.
And then all this gets even more tricky when we start talking about more frequent delivery through modern development methodologies like DevOps. Do you have time in a two-week sprint to define and create all the new scripts you might need, as well as analyze your test library and make all the necessary updates? I’m going to say ‘unlikely’ to that one.
Sure, I’m painting a bit of a picture of the apocalypse here. Large organizations with complex landscapes and fully manual processes are going to find this situation harder than most. But even today’s automation tools aren’t much more than band-aids. They still rely on some form of test script that has to be created at the client-side of the system and maintained afterwards.
What if I told you there was a better way? A way that removes the need for test scripts as we know them, which automatically creates a comprehensive library that can be refreshed on demand?
Robotic Test Automation: A Better Way to Test
Robotic Test Automation (RTA) is a leading-edge technology that automatically generates, executes and maintains regression test libraries based on real-world use, automatically learning and validating SAP system behavior without user intervention. It can fully replicate a day in the life of your regular business.
RTA eliminates time-consuming end-user recording, business process discovery, test script creation and maintenance chores – along with all the test data management associated with the process – to perform system-wide SAP regression tests in days, rather than months. Set-up time is negligible. No manual intervention is required. And, with it, you can begin to approach 90 percent test coverage – without any scripting required.
The benefits of RTA are clear. With it, you suddenly have the freedom to accelerate major SAP transformation projects, including cloud and HANA adoption, and safely experience the benefits of DevOps.
RTA gives you the ability to test more of what’s beneath the surface, so you can proceed confidently along your business transformation journey. Because the system updates itself, without any manual effort, testing can be shifted left, speeding and sustaining delivery. And, by automating the testing process, RTA removes the testing burden from DevOps teams better suited to creating and supporting a competitive, agile and relevant business.
It’s time to say goodbye to test scripts.
Contact us today to book a demo or visit the Testimony product page for more information.
