Automated E2E testing for SAP is a mouse trap! Don’t fall for it – Decouple instead.
Why Automated E2E testing for SAP projects is a trap?
Automated E2E testing sounds like dream come true for SAP S/4HANA complex transformations (Selective Data Transitions/BlueField or Complex Brownfield projects) but in reality it’s a hidden mouse trap.
On one hand, thoroughly testing your system in a production-like test environments sounds like a great idea but in reality it’s only doable for very simple systems. When we talk about SAP transformation projects like Selective Data Transitions/BlueField or Complex Brownfield projects where we have hundreds of 3rd party systems and even more EDI/B2B partners it start to resemble a Greek myth of Sisyphus (can never be achieved). It’s brilliantly explained in this video from David Farley author of “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”.
What makes E2E testing fail for SAP projects?
Imagine having to run a complex SAP transformation program with 30-100 SAP consultants and many more internal resources which need to work together. Now someone comes to you and says the best way to run this program is to enable E2E testing so whatever change the SAP team will do will be automatically validated. While it’s a great idea in reality you don’t add 5-10% of more work to the scope of the project as with 50-100 3rd party systems and 200-500 EDI partners you may actually be doubling or tripling the project scope – were you aware of that? Doesn’t that remind “spinning too many plates”? Are you such a good coordinator and is your SAP project budget owner are of the additional costs?
Image source: https://halfretire.com/why-selling-a-business-is-a-million-dollar-aspirin/
It doesn’t end here I’m afraid, E2E testing setup would be deployed by people who are not involved in the software development process and don’t know the functionality of those 50-100 3rd party systems. Testing teams in such situations tend to be overly cautious and test everything due to concerns about potential issues. This approach can be slow, costly, and not very effective at ensuring high quality. Also the problem is that testing is happening too late in the process to catch and prevent quality issues from occurring in the first place.
Solution – Simulate to Isolate and Decouple your SAP project
As Dave Farley mentions a good test is deterministic and atomic so the key to solve this puzzle is to use simulation to isolate and decouple SAP project from 3rd party systems and EDI/B2B partners as shown in Figure below.
Figure – Simulate 3rd party systems and EDI/B2B partners for SAP projects.
It simplifies the following:
a) scope of the project – you’re only testing the releasable unit of software – SAP system and not anything else
b) we can test every aspect of the releasable unit of software in a much better way instead of testing only vanilla flows with E2E testing
c) by simulating 3rd party systems and EDI/B2B partners we speed up the SAP project as we eliminate the need to coordinate the testing with multiple parties
d) our SAP project can be more sustainable – no need to create matching tiers of test environments of 3rd party systems and the existing ones don’t even need to be online during the testing
This method is a much more organised and structured approach to conducting comprehensive and detailed testing of SAP transformation programs, and it is more efficient and quicker than the E2E alternative.
Where I can learn more about this topic of Simulations/Service Virtualization for SAP transformation programs?
There’s a 3h course on openSAP just on this topic called “Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization” – In this course we help you understand why SAP-tailored service virtualization is a hidden gem of SAP S/4HANA projects, who can use it and when to use it, and most importantly, how to benefit from it. In addition, you’ll learn how service virtualization can make your projects more sustainable by significantly minimizing their carbon footprint.
Figure – openSAP course on service virtualization