Robotic Test Automation Brings Ends To Scripting

Robotic Test Automation Brings Ends To Scripting

Scripts always brings an expression that can foray fear into the hearts of the most fearless team of developers, QA experts and project managers as they try to deliver changes into an SAP system on time and under budget.

Well, possibly not so much ‘fear’ as a discouraging sense of acknowledgement.

The fact is, test scripts are an essential part of pretty much all the traditional approaches to SAP 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 particularly right for testing where much of what you’re trying to test is ultimately related to business processes and the related aftermaths. The best of you will have those processes represented 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 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 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 pioneering technology that robotically generates, executes and maintains regression test records based on real-world use, automatically learning and substantiating SAP system behavior without user involvement. It can fully replicate a day in the life of your regular business.

RTA eliminates inefficient end-user recording, business process encounter, 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.