Testing SAP after minor changes – how to do it effectively?

Testing SAP after minor changes

In the cloud world, the so-called “minor changes” might not be as small as they tend to look. So thorough testing in the business-as-usual phase is more important than ever before. 

The article that you are about to read was written based on the conversation between Michał Krawczyk and Michał Kowalczewski regarding testing SAP after minor changes. Find the full conversation below:

Having said that, if you deal with a lot of minor changes in your SAP environment and want to become more effective at testing them, then this article is definitely for you.

What happens after the go-live of big SAP projects?

Let’s say all transports are already in the production environment, everything is working as it should and hypercare is not much involved. But the go-live is not by any means a stop of changes. From this point on, there would be a lot of minor changes made.

Usually after go-live, the project team gets slowly dissolved and everything that is related to SAP (like maintenance and support) is passed to the teams that are called “Business-as-usual” – BAU in short.

Passing of the responsibility is a crucial moment in SAP Projects

Good transition to the BAU teams is critical for the success of the whole implementation. You need to ensure proper knowledge transfer and pass the responsibility to the new team members, who, most of the time, would be new to this project.

From the perspective of not only testing SAP, but also from every other angle, there are a lot of differences between SAP Projects and BAU. For example, from the budget perspective, a project would have its own, dedicated budget. But for BAU, this is a continuous process. So maintenance and support would be financed in a different way.

Are business-as-usual teams only making small changes that don’t call for testing?

This would of course depend on the organization, but business-as-usual teams are usually focusing on minor changes that could be covered by the maintenance budget.

But the point is – this doesn’t mean that these minor changes don’t need to be thoroughly tested. Because in terms of testing SAP – it doesn’t make a difference if this is a minor or a major change.

And why is that? The reason is simple. You need to ensure business continuity. And there’s no other way of making sure that the critical business processes are working properly aside from testing them.

Testing SAP APIs after minor changes is important because of the dependencies

When we’re talking about Global Enterprises that use SAP in a more centralized manner, it’s important to remember that we can rarely talk about API that are not burdened with dependencies. Which means that these changes might not be as small as they seem to be at first glance.

Learn more about External Dependencies in SAP from one of our last conversations in the Navigating SAP API Testing cycle:

When it comes to making a change related to API, you are never sure about the exact impact. Because unlike working with the UI alone, you’re likely working in a reusability mode. So you would probably like to centralize everything and then reuse it. But this has a higher cost when it comes to testing. 

In short, you need to make sure that each process is working properly after making even the smallest changes… and some of the time, you might not know which processes could be affected.

Are your “small changes” really that small?

Please remember that even a change as small as simply changing two lines of code, might be affecting hundreds of systems. And to illustrate this point about Testing SAP, let’s look at an example from the aviation industry.

Let’s imagine that you need to drill a single small hole in the wing of an airplane.

In order to literally drill this hole, you’d need a working drill and about 2 minutes of your time. But in order to do it properly you first need to study the airplane – its construction, documentation, wiring and so on. Just to make sure that you will not cause any problems or side effects. And this is similar to making changes in the Enterprise Software.

The changes that are made in the systems are not done in isolation. The system that you’re changing would usually be a part of a bigger environment. And any small change can cause ripples.

Testing SAP in business-as-usual phase can be challenging

Testing your SAP system after making small changes in the business-as-usual phase can be hard, because it’s rarely possible to involve business in such testing. So planning and finding interested business resources who will be able to dedicate their time to testing the “minor changes”. Yet the consequences of making any change, as we mentioned earlier, can be very important from the business perspective.

So even though these might look like “minor changes” – for example from the coding perspective – the preparation and the testing might actually be the same or even longer than in a normal project because you need to arrange dedicated people to support you, which is usually a given in a project.

Switching from on-prem world to cloud world changed the game

In the past (the on-premise world) when you needed to do an upgrade or technical migration to a new system version, you needed to raise a project, which was separate from the BAU. You had your project schedule and in this plan you had an official testing cycle. So business resources were available. 

In the cloud world, the changes are provided in a continuous way. So for example biweekly. Which means that it’s not possible to organize it and you’re no longer in charge of the schedule. This is coming from your software vendors. And if you’re using multiple software components to run your business processes, the changes might be made daily.

Of course, the software is carefully tested by the vendor. But it’s tested in isolation. Not in the configuration that is running at your organization, where you are integrating it with other software components through APIs. So YOU need to make sure that these changes do not affect your APIs and business processes.

And because you’re dealing with such minor changes all the time in the cloud world, the ways of working need to change as well. Your organization needs to find a way to continuously move them to production without creating risk. And the solution to that can be Automated API Testing. So if you want to speed up testing and improve quality, here’s a video explaining this concept for you:

How to use modern technology such as Int4 Suite to test your SAP after minor changes?

The integration in enterprises is built on integration platforms. And the integration platforms are storing historical data – that contain hundreds of variants of your business processes. 

With Int4 Suite you can grab all the historical data and put them to good use by easily turning them into test cases. With that you can dramatically increase the coverage of testing.

In order to better understand this feature, make sure to watch this video, which explains how you can create thousands of test cases in minutes with Int4 Suite:

Int4 Suite is being used by many of the Fortune 500 companies and it’s a great, modern addition to your SAP testing toolstack. 

If you’d like to learn more about how you can utilize the powerful capabilities of Int4 Suite, schedule a discovery session with our team. See you soon!