End-to-End (E2E) testing in SAP environments is often complex and involves many teams and stakeholders. End-to-end testing is the responsibility of and executed by the test team (and (future) users). It is intended to demonstrate that the consecutive series of systems support the business processes according to specifications and business needs. End-to-end testing has many approaches, in this training we will focus on the Vertical and the Horizontal approach.
The following business challenges emphasize the need for end-to-end testing:
- Demand for seamless SAP workflows, analytics, and integrated customer experiences.
- Complicated global and increasingly diverse integrations of many applications and data stores.
- Keeping up with upgrades/ updates of SAP and legacy applications to deliver changing business demands, while managing security and compliance.
The subject “end-to-end testing within SAP” has 4 main building blocks:
- Vertical end-to-end testing
- Horizontal end-to-end testing
- Scope and approach
- Stakeholders
Vertical end-to-end testing
In SAP, "Verticals" refers to software solutions, line of businesses or modules that are designed to provide common functionality that can be used across multiple industries or business sectors. Verticals in SAP typically include solutions that provide core business functions that are common across all industries. Some examples of vertical solutions in SAP include SAP S/4HANA Finance, SAP S/4HANA Supply Chain, SAP S/4HANA Sales, SAP S/4HANA Procurement, and SAP S/4HANA Marketing. A vertical can also be an essential non-SAP system which is part of the eco-system.
Different names (synonyms) used for Verticals in SAP testing are:
- Domains
- Modules
- Solution Trains
- Streams
- Line of Business
- Or any other fancy project terminology an organization is using
Within SAP projects these verticals are tested during a system integration test (SIT) mainly with wide authorizations, meaning that role-specific authorizations are not in place yet. The main goal is to verify and validate that the vertical processes are working and meet business needs.
Each vertical needs to work fine before we can bring the solution one step higher to the overarching end-to-end testing which is “horizontal end-to-end testing”.
Horizontal end-to-end testing
The next phase is to test the complete end-to-end business process (including legacy systems, 3rd parties, overarching modules, different platform solutions and authorizations). It focuses on how the complete eco-system works together and how data and processes are behaving when we push data through the end-to-end business scenarios. Within the vertical and horizontal testing, test data management is key, for verticals it is a little easier to manage test data then during the horizontal end-to-end test. Big risks and challenges during the horizontal testing are the availability, synchronization, alignment and dependencies on test data.
During horizontal testing, full integration and the complete business role authorizations should be available. Before starting the horizontal end-to-end test (which involves user acceptance), one of the most important quality criteria to start this phase is that the full solution must be ready, in place and available in the test environment. In these criteria attention is paid to:
- (Master) Data available,
- Integrations are available (API),
- An Application Programming Interface (API) is a messenger that allows two applications to talk to each other. An API delivers a request from one system to another, then returns a response.
- Users are set up,
- Business Role Authorizations are in place,
- Scope is clear.
When one of these key prerequisites is not in place, DO NOT start with the Horizontal end-to-end testing. In the weeks prior to this testing phase, manage and control with all project stakeholders that these preconditions are worked on, that the tasks and activities are allocated and assigned and part of the integral project plan. Discuss progress frequently. Setting up role base authorizations in SAP is a long, tedious, complex and skilled activity executed by the Security Team. Working closely together with all sub-projects to define the needs and align with stakeholders that within the project planning all these activities come together at the start of the horizontal end-to-end tests that includes the user acceptance test (UAT). When one of the sub-projects is delayed (e.g., data migration/ integration/ authorizations), the horizontal end-to-end test should not start!
To improve quality early in the development lifecycle and to simplify the SAP landscape and integration dependencies, service virtualization can be introduced. Service virtualization simulates the communication between the systems without using these systems physically. Benefits of using service virtualization are:
- Start SAP testing early in the project,
- Less dependent on test data,
- Less dependent on system availability.
Service Virtualization can minimize dependencies from external systems and streamlines end-to-end testing.
Scope & Approach
For end-to-end (E2E) testing (both vertical and horizontal), it is important the test scope is clear. Which processes, which scenarios, which integrations, which systems etc. are in scope (and which are out of scope). The SAP Quality Risk Analysis is a good input to define E2E testing and connect the individual processes to an E2E process. However, to build proper E2E scenarios, you need to have input from the specialists (business owners and functional/ technical resources). The one who is (or will be) using the system most, the end user, is the best specialist out there. They should know what the business needs are to achieve the business value and how the system should be used.
As soon as the E2E scenario (process-wise) is defined, it is important to define the data you want to validate (data-wise). Process-wise is a forward-thinking process, data-wise is a backwards thinking process. For determining the test data needed, start at the end of the process with the last team in the E2E scenario (often Finance) and ask them what they want to validate, what specific conditions they want to check in the, for example, general ledger or cost & profit centers. When this is known, it is important to think backwards which product, material, service, ship-to-party/ sold-to-party and or client you want to use to validate this outcome. Determine the output and manage the (master) test data. Work backwards to make sure the data is aligned, available in all systems (enough stock, customer and sold-to parties are in sync and available, material numbers exist etc.).
When this is all in place, documented and agreed, you are ready to execute the horizontal E2E test. To track progress of the E2E test execution, a test management tool is recommended where you can assign different steps in the E2E flow to different resources/teams.
Preferable, to do efficient, effective and faster manual E2E test execution, bring all involved E2E stakeholders in the same room. This will increase and improve communication, accelerate execution, increase understanding and will contribute to team building.
Stakeholders
When setting up a test organization & test team, it is important to include stakeholders from all solution trains and modules. A wide knowledge of business processes is required to be able to test properly, especially within the horizontals. It is also important to have stakeholders (like process owners) in your test team who have mandate and the power to change procedures and processes whenever this is needed and who are able to determine impact of these changes.
Stakeholders can be local process owners (they own the process for example for specific locations or regions) and there are global process owners, who own and oversee the impact of changes on a global level). Changes made for a specific region might impact the global solution or other regions which local process owners do not always oversee. It is important to have a mix of these business people in your test organization & test team, especially when designing and executing the E2E flows.
Creating awareness and ownership
Key users who are involved in testing are more likely to feel ownership of the SAP solution and its success. By involving them in testing, they become more familiar with the SAP processes and are more likely to adopt it and use it effectively. They are part of the journey to become the ambassador of the change.
However, ownership of SAP quality engineering should be implemented on operational, tactical and strategical level. For example, who owns:
- Test data and test cases
- Test policy and strategy
- Test planning
- Test environment
- Test tools
- Test processes
- Authorizations
- Business processes
- ….
Quality awareness must be addressed throughout the whole (project & operation) organization. With quality ownership comes quality awareness. Early quality awareness of stakeholders improves the entire result of the SAP solution.