Untangle the mess: Line up your SAP End-to-End Testing

Preparing test scenarios is always a conscious and intricate activity. End-to-end testing emphasizes this even further. And instead of dealing with clear consecutive processes, SAP end-to-end testing shows a reality where a whole mesh of interchanging business process steps is far more likely. How can we approach this form of testing and get a grip on this important SAP test variety?

This is a blog topic in a series of blogs about TMAP: Quality Engineering for SAP. It is about the continuing need for end-to-end testing within an SAP environment and elaborates on which approaches can be used to structure an SAP end-to-end Test operation.

The necessity of end-to-end testing in an SAP context
Nowadays, IT delivery is often aimed towards Agile ways of working, including elements like fast and continuous delivery, frequent releases, self-organizing teams deciding on what and when to test and having a focus on a team’s Minimum Viable Product. This might lead to less extensive test scenarios or more Contract Based Testing via Application Programming Interfaces (API’s) to ensure that two systems can indeed successfully exchange information. However, for SAP testing there is still a lot of value in making sure that the end-to-end (E2E) functionality of a business process, supported by one or more systems, is properly checked. Think of validating full workflows, user-facing functionalities, realistic test scenarios and ensuring that data is continuously handled and recognized in the right way. These aspects of SAP testing underscore the need for SAP E2E testing, but how do you get started?

Getting your lines ‘straight’
Because SAP software can cover many different business processes and related IT activities, it can become confusing to create order in the overlapping and mixing team- and system connections and dependencies. Questions that might arise are: How does each team handle the incoming and outgoing (Master) data? Which interfaces are connected and how are they synchronized? Which authorizations allow for which actions and how are workflows maintained when they are present in systems developed by multiple teams? 

A recommended starting point for structuring these questions and, with that, your SAP E2E testing is by starting with a Vertical Approach. From this angle, you focus on SAP or non-SAP software solutions or modules that are designed to provide common functionalities and which are used across multiple industries or business sectors. Other terms describing Verticals are Domains, Lines of Business or Solution Trains. Taking this as your E2E test approach, you organize your test scenarios to include processes required within one domain only, like Finance and Accounting, Supply Chain Management or Sales. 

Once these vertical E2E tests have been completed on an acceptable level (meaning that the full solution is ready enough and fully testable), it is time to move on to the Horizontal Approach. Now, testing is aimed towards checking business activities that are spread out over multiple domains and legacy or third party systems. In other words, you are going to include integrations and data handling over multiple systems and technologies. For example, should your company be in the business of selling pens, a horizontal E2E test could track the activities from warehouse management to procurement to receiving sales/e-commerce orders, collecting customer information via a CRM system, managing pen deliveries, processing invoices and finances and updating stock for new, future orders.

These horizontal E2E tests involve multiple development and key user teams from multiple domains and as such pose challenges related to system and people availability, synchronization, alignment, setting up fully integrated business role authorizations and having dependencies on (other team’s) test data. Therefore, make sure to always prepare well.

To ensure successful E2E testing, think of having the following (critical success factors) in place:

• Test scope is clear: Gather input from business owners, end users and technical specialists and using the output of an SAP Quality Risk Analysis.
• Integrations are available: Think of API’s which allow systems to talk to each other.
• Business Role Authorizations available in the systems: set up with assistance from a Security team.
• (Master) Data is available in the right environment: define the necessary test data by thinking data-wise. Check in with the last team in the horizontal E2E test scenario and ask what they need to validate. Then trace back through the other involved domains/teams to make sure your test data set is complete for all parties.
• Prepare Key User participation: For those who will participate in the User Acceptance Testing, make sure they can access the systems properly and know when they are expected to test.
• Test Management tooling is prepared: including the setup of efficient test management and anomaly management processes.
• Progress meetings are planned in with relevant stakeholders: to make sure that they are involved early, frequently and effectively (keep them engaged and use their expertise to improve process and product quality).

The close involvement of business stakeholders is essential for completing a successful horizontal SAP E2E testing phase. For more on this, see our earlier blog “Why are Key Users essential in SAP Testing?”.

SAP end-to-end testing is not something to be taken lightly. It is an activity which needs in-depth technical knowledge regarding the involved software (and sometimes also hardware) and their integrations, business expertise on how data should be handled over multiple domains and platforms (ex. on premise, cloud, or hybrid) and strong know-how on how to organize this in either sequential, Agile or hybrid working environments. Make sure to be properly prepared and coordinated and use the existing expertise of your colleagues to achieve a successful and agreed upon result.

Future blogs will explore more topics related to SAP Testing and how they can be organized and executed. So, feel free to check in again to learn more about how Quality Engineering within the realm of SAP serves its stakeholders and strengthens SAP implementation processes.