In this article you will learn:
- How to build the regression test cases with Int4 IFTT
- Why should you do automated testing while SAP PO migration
- What are the benefits of the robotic way of test case creation
Introduction
One of the most common use cases for test automation is SAP PO migration. We would like to share with you the progress and the characteristics of the recent project that involved Int4 IFTT. This article is a more detailed version of a Case Study that is also available on our website.
Scope of the project
The scope was an SAP PI dual-stack migration into SAP PO 7.5 in the large pharmaceutical company. As the IT landscape is SAP centric, the role of SAP PI and now SAP PO is crucial. There were about 1200 flows in the scope of the migration. The overall message volume is close to 1 million messages per day.
The project was delivered jointly by internal IT and the onsite and offshore consultants from one of the big integrators. The role of Int4 was to provide a platform for test automation and enable building the regression test cases by Int4 IFTT and its robotic crawler.
The challenges
We identified the following challenges for the project:
- Broad scope and volume of messages
- Lack of full knowledge, how some of the scenarios work. Some scenarios are older than the team that is currently maintaining them.
- Small team compared to the project scope.
- cTight schedule. The project schedule was dictated and limited by an upcoming large S/4HANA project. The SAP PI/PO migration must be accomplished before it. The other important point is the end of support for SAP PI 7.X that will happen at the end of this year.
- No testing support outside the team, due to the technical nature of the project.
The bright side of the project was a fact that SAP PO 7.5 is a well-known and stable integration platform. SAP provides a set of tools to perform the migration process semi-automatically.
Automated Regression Testing with Int4 IFTT
Let me now focus on testing. Typically, the full cycle regression testing must be conducted to make sure that the integration between systems will work unaffected on the new platform.
The team management consciously noticed that test automation is the only way to perform the migration smoothly and choose Int4 IFTT for it (after the short pilot project).
The expectations were high, but we knew that Int4 IFTT would solve the following issues:
- Virtualization all the sender and receiver systems. The team will not need to work with non-SAP parties to trigger the test data until the final UAT
- Automatic test case creation based on the robotic approach and scanning the production SAP PI system
- Change the project delivery methodology to Test Driven Development. Int4 IFTT impacts not only the testing, but the project delivery thanks to the shift left, and test-driven development (TDD) approaches.
As it is widely known, test automation is a solution for immediate test case execution. However, having such a large scope, the issue was to create representative test cases for each scenario. Here customer entrusted it to the Int4 IFTT Robot. The robot monitored the production environment and created test cases based on successfully processed messages. Those messages were treated as reference data and all test runs were validated against it.
This sounds great in theory, but what are the real steps and the effort?
The details are the following:
First, we needed to define the requirements. Based on the SAP PI ICOs and classical configuration objects, extracted by Int4 IFTT, the customer prepared an excel spreadsheet. The sheet was matched and updated with the WRICEF identifiers and the interface master list. In the next step, the customer designed the test case structure (folders based on project phases and functional assignment) and a number of expected test cases per each combination. In this case, we assumed that 20 messages for each interface and sender/receiver combination were enough.
Finally, all the above was imported from a single spreadsheet to the Int4 IFTT Robot Configuration.
The production SAP PI keeps the successfully processed messages only for 1 day.
So, as a next step, we scheduled a job that executed the robot on a nightly basis. This was not so obvious, but even if there are 1200 scenarios, it doesn’t mean that all the interfaces were triggered during one day. Hence the robot needed to work for 2 months and still didn’t find all messages for each combination of an interface and all the possible senders and receivers. This is driven by the business nature of the exchange information. Some documents are created in thousands every hour, once others might be a single message per month or even less frequently.
It was also an excellent opportunity to review the active interfaces. The ones that, after that period, Int4 IFTT Robot couldn’t find messages, were categorized as candidates for decommissioning.
Robotic way of test case creation
The robotic way of test case creation was a booster. But the real fun and the game-changer was just to begin.
In the meantime, the development team was firing on all cylinders and migrating the interfaces one by one. From day one, for interfaces that the test cases existed, we enabled testing.
Moreover, as the test data source was production messages, it was a UAT quality, not simple unit tests. Int4 IFTT enabled both shift left and test-driven development approaches. Developers were able to run on the development box the full UAT set of test data (Shift-left) and fix the data immediately before moving changes to other environments or wait for testing. If the test run identified errors, developers were fixing the issues until the successful run (Test Driven Development). The Int4 IFTT execution results and findings were very interesting. Hence we prepared a separate article that focuses more on the technical issues.
As the scope was significant, we split it and worked in cycles. The process for each phase looked similar:
- Identification of WRICEFs and interfaces to be migrated in the particular phase
- Load the requirements to Int4 IFTT Robot and schedule night jobs till the test cases were created
- Migrate and develop interfaces in development environments. Run the testing continuously until all test cases are passed
- Move the content to the Quality environment and configure the channels
- Run the Int4 IFTT test cases and solve the potential issues
- Run the simplified UAT with business users
- Move the content to the Production system. Configure and start the channels
- Monitor the flows in the hyper care mode
- Close the phase
Conclusion of the project
Thanks to full automation, both test case creation, and execution, the project was implemented much faster than in a regular way. The most important fact is zero critical issues during the production hyper care period. Besides, the customer was satisfied and felt safe during it, having very good evidence of regression testing.
For the client, the SAP PO migration is just a starting point. The effort for Int4 IFTT implementation and the test cases preparation will be now and, in the future, charged back during the daily maintenance and support all the projects in the SAP PO area.
