TMAP®:

Quality Engineering for SAP

Syllabus

Version 1.0
Released 10 November 2023
 TMAP: Quality Engineering for SAP – syllabus

Copyright notice
Copyright © Sogeti Nederland B.V. 2023. All rights reserved.
This document may be copied in its entirety, or extracts made, if the source is acknowledged.
Any individual or training provider may use this syllabus as the basis for a training course if Sogeti is
acknowledged as the copyright owner and the source of the syllabus.
Any individual or group of individuals may use this syllabus as the basis for articles, books, or other
derivative writings if Sogeti is acknowledged as the copyright owner and the source of the syllabus.

TMAP® is a registered trademark of Sogeti Nederland B.V.

SAP®, SAP Fiori® and SAP S/4HANA® are trademarks or registered trademarks of SAP SE or its
affiliates in Germany and in other countries.”

Revision history
Version Date Author Remarks

Initial setup and instructions for

0.1 18 July 2022 Rik Marselis
contents creation.

Rik Marselis & Setup of order of learning objectives

0.2 28 December 2022
Pepijn Paap and chapters with extra knowledge.

Rik Marselis & Learning objectives & extra know-

0.3 3 March 2023
Pepijn Paap ledge chapters for internal review.

Rik Marselis & Version for initial review by SME’s

0.4 31 March 2023
Pepijn Paap and SAP community

Rik Marselis & Version for team that creates pilot

0.5 26 April 2023
Pepijn Paap training material.

Rik Marselis,
0.6 12 May 2023 Pepijn Paap & Version for TMAP SIG members
Guido Nelissen

Rik Marselis & Version for internal pilot-training

0.7 24 May 2023
Pepijn Paap course

Rik Marselis & Version for external pilot training

0.8 26 July 2023
Pepijn Paap course

Rik Marselis &

0.9 18 August 2023 Version for initial live training course
Pepijn Paap

Rik Marselis &

1.0 10 November 2023 Final version
Pepijn Paap

Public. Copyright © 2023 Sogeti. All rights reserved 2

 TMAP: Quality Engineering for SAP – syllabus

Table of Contents
Table of Contents .................................................................................................................. 3
0. Introduction to this syllabus ............................................................................................ 5

1. Session 1 ................................................................................................................... 11

2. Session 2 ................................................................................................................... 15

3. Session 3 ................................................................................................................... 19

Public. Copyright © 2023 Sogeti. All rights reserved 3

 TMAP: Quality Engineering for SAP – syllabus

4. Session 4 ................................................................................................................... 22

5. Description of additional subjects – ERP & SAP ................................................................ 25

6. SAP quality management.............................................................................................. 41

7. SAP Infrastructure and tooling ...................................................................................... 57

Public. Copyright © 2023 Sogeti. All rights reserved 4

 TMAP: Quality Engineering for SAP – syllabus

0. Introduction to this syllabus

TMAP®: Quality engineering certification scheme

The TMAP® certification scheme supports people involved in IT delivery in extending their knowledge
and skills, to empower them to play their part in delivering business value for their organization, its
customers and other relations.
The TMAP® book “Quality for DevOps teams” (2020) is the foundation of the TMAP® body of
knowledge. The website www.TMAP.net contains most of the knowledge from the book and many
additional items such as downloadable templates and the TMAP® glossary (in 5 languages).
In today’s IT world cross-functional teams are expected to deliver business value with the right
quality at speed. This requires high-performance IT delivery models such as DevOps and Scrum,
which can be extended to a hybrid IT delivery model such as the SAFe® framework.
The TMAP® body of knowledge for quality engineering and testing supports working towards built-in
quality and takes the need for quality in products, processes and people far beyond just testing.

Purpose of this syllabus

The training course “TMAP®: Quality Engineering for SAP” enables professionals that are
responsible for accepting and implementing SAP systems, to acquire the necessary knowledge and
skills to enable them and their teams to achieve quality ownership.
This syllabus is the basis for the training course “TMAP®: Quality Engineering for SAP” and provides
directions for the associated examination and certification. This is a 2-day training course, consisting
of four sessions. The candidate can achieve a certificate by taking a separate exam of 1 hour.

Target audience and prerequisites for candidates

This training course is mainly intended for key users, business users, operations and maintenance
teams. These are the people that often are involved in testing and implementing new or changed
versions of SAP systems and whom are involved in the acceptance process.
The candidates are expected to have basic IT knowledge and experience, and average SAP
knowledge and experience. There is no required previous certification.

Format of the training course and this syllabus

The 2-day training course consists of 4 sessions with a minimum of 3 hours (that is 12 contact hours
in total). The number of hours mentioned is excluding homework (such as self-study), logistical
preparation of the exam and breaks. Candidates must prepare to spend about 6 to 12 hours on
individual study and preparation for the exam.
The order of chapters and sections in this syllabus is according to the sequence of the training
course, which gives a mix of theoretical and practical subjects. Every training session is a separate
chapter in this syllabus and the sections each cover a learning objective.
The chapters 5 through 7 of this syllabus contain supporting knowledge from the TMAP body of
knowledge, which is additional to what is described in the TMAP book “Quality for DevOps teams”.

Public. Copyright © 2023 Sogeti. All rights reserved 5

 TMAP: Quality Engineering for SAP – syllabus

Learning objectives and K-levels explained

Learning objectives (LO’s) are brief statements that describe what you are expected to know after
studying each subject. The relevant information for the learning objectives can be found in the TMAP
book “Quality for DevOps teams” and in chapters 5, 6 and 7 of this syllabus. With each LO there is a
reference to the relevant chapter(s) or section(s). The LO’s are used to create the examination for
achieving the TMAP®: Quality Engineering for SAP certification. Each learning objective has a
corresponding cognitive level of knowledge (K-level).
These K-levels, based on Bloom’s modified taxonomy, are as follows:
▪ K1: Remember (knowledge). The candidate should remember or recognize a term or a concept.
e.g. is able to recognize, has knowledge of, knows.
▪ K2: Understand (comprehension). The candidate should select an explanation for a statement
related to the questioned subject.
Examples are: The candidate… can explain, recognizes examples related to the subject,
understands, is able to recite, is aware of, can indicate, can distinguish.
▪ K3: Apply (application). The candidate should select the correct application of a concept or
technique and apply it to a given context.
Examples are: The candidate… can relate, can enumerate, can select, can compose, can identify,
is able to apply, can assign, can propose.
An overview of the learning objectives and their corresponding K-levels is given in the next section.

Learning objectives and K-levels for this certification

The literature referred to in the last column of the table below, are the TMAP book “Quality for
DevOps teams” (3rd edition 2022) and the chapters 5, 6 and 7 of this syllabus.

Section
Learning objectives
K-
(the order is basically appearance in the
level in this Literature in the
sessions, with a few exceptions)
syllabus book or syllabus

LO01 ERP Systems K2 § 1.1 Syllabus § 5.1

LO02 What is SAP K1 § 1.2 Syllabus § 5.2

Syllabus § 5.2 &

LO03 SAP Main flows K2 § 1.3
5.3

LO04 Other SAP solutions K1 § 1.4 Syllabus § 5.4

Ch 7 introduction,
§7.1, Ch 8
introduction, §8.2,
LO05 IT delivery models for SAP K2 § 1.5 Ch 9 introduction,
§9.1, Ch 10
introduction, §10.1.
Syllabus § 5.5

§1.2, Ch 5
LO06 Introduction to Quality Engineering & Testing K2 § 1.6
introduction, Ch 11

Public. Copyright © 2023 Sogeti. All rights reserved 6

 TMAP: Quality Engineering for SAP – syllabus

Section
Learning objectives
K-
(the order is basically appearance in the
level in this Literature in the
sessions, with a few exceptions)
syllabus book or syllabus

LO07 Business value and the VOICE model K2 § 1.7 Ch 3

Ch 1 introduction,
§1.2.1 (of 3rd
LO08 Introduction to built-in quality K2 § 1.8
edition), Appendix:
A.1, A2, A3 and A.4

§3.3, §5.2, §5.4

LO09 Stakeholder management in SAP projects K3 § 3.1
Syllabus § 6.1

§3.3, §5.2, §5.4

LO10 ARCI matrix for stakeholder responsibilities K3 § 3.2
Syllabus § 6.2

LO11 The SAP Project K2 § 2.1 Syllabus § 5.6

LO12 SAP Activate K1 § 2.2 Syllabus § 5.7

Ch 26, §5.2.1,
LO13 SAP Quality Risk Analysis K3 § 2.3 §5.2.2
Syllabus § 6.4

§15.4.3, §26.5,
LO14 SAP Test Strategy K2 § 2.4 §26.6
Syllabus § 6.5

Ch 11, § 15.4.3
LO15 SAP Test Plan K2 § 2.5
Syllabus § 6.6

§ 10.1
LO16 Quality gates K1 § 2.6
Syllabus § 6.7

Ch 30, Ch 43,
LO17 Test Design - Introduction K3 § 1.9
§ 45.1

LO18 Test Design - Equivalence Partitioning K3 § 2.7 § 46.5

LO19 Test Design - Boundary Value Analysis K3 § 2.8 § 46.5

LO20 Authorizations managed with RBP K2 § 3.3 Syllabus § 5.8

Ch 3, Ch 33, Ch 37
SAP End-to-end testing vertical and introduction,
LO21 K2 § 3.4
horizontal § 37.5.1
Syllabus § 7.7

Ch 31
LO22 Test data (management) in SAP K2 § 3.5
Syllabus § 7.1

LO23 SAP organizational change management K2 § 3.6 Syllabus § 6.3

§ 5.5, Ch 33,
LO24 SAP test execution K2 § 3.7 Ch 34,
Syllabus § 6.8

Public. Copyright © 2023 Sogeti. All rights reserved 7

 TMAP: Quality Engineering for SAP – syllabus

Section
Learning objectives
K-
(the order is basically appearance in the
level in this Literature in the
sessions, with a few exceptions)
syllabus book or syllabus

Ch 4, § 5.4,
LO25 Indicators and Test Reporting K2 § 4.2 Ch 19 introduction,
§ 19.1, § 19.2

LO26 Test Design - Path testing K3 § 3.8 § 46.3

Ch 18
LO27 SAP Anomaly Management K2 § 4.1
Syllabus § 7.4

§ 1.2, § 1.2.1 (not

LO28 Continuous everything K1 § 4.3 §1.2.2 and §1.2.3),
§ 6.2

§ 6.1, § 6.2
LO29 SAP and CI/CD pipelines K1 § 4.4
Syllabus § 7.2

Ch 12, § 23.1.2
LO30 Test Management Tooling for SAP Projects K2 § 4.5
Syllabus § 7.3

Ch 23 introduction,
LO31 SAP Test Automation & Tooling K1 § 4.6 § 23.1, § 32.1,
§ 32.2, Syll. § 7.5

§ 38.1, § 38.2
LO33 SAP Performance Testing K1 § 4.7
Syllabus § 7.6

LO34 Test Design - Exploratory Testing K3 § 4.8 § 36.1, § 47.4

Note: LO32 was deleted and no longer exists.

The TMAP®: Quality engineering for SAP - exam

The format of the exam is multiple choice. There are 25 questions. There are no explicit questions
regarding K1 learning objectives. Each correctly answered question for a learning objective at K2- or
K3-level gives 1 point. There are 17 K2 questions and 8 K3 questions so in total 25 points can be
gained. To pass the exam, at least 66% of the points (that is 17 points) must be gained.
The candidate has one hour to complete the exam. This time is sufficient for non-native speakers.
The only reason for getting extra time would be medical reasons, such as dyslexia, in that case
contact the exam provider before scheduling the exam.
The exams and certificates are provided by the independent exam provider iSQI.
For more information about exams please visit: www.isqi.org or www.TMAPcert.com.

Public. Copyright © 2023 Sogeti. All rights reserved 8

 TMAP: Quality Engineering for SAP – syllabus

Brief introduction to the other TMAP certifications

The TMAP® certification scheme tailors to the needs of four target audiences. The figure below
shows the certifications and indicates that the first certification “TMAP: Quality for cross-functional
teams” provides knowledge necessary for two other certifications. The figure also shows that
TMAP:Quality Engineering for SAP is aimed at key users, business users, maintenance – and
operations teams that are involved in accepting and implementing SAP systems.

Besides TMAP:Quality engineering for SAP, there are three other certifications in the TMAP
certification scheme, as listed below.
Many people are working in, or are related to, a high-performance IT delivery team, such as in
DevOps or Scrum. In the training course “TMAP®: Quality for cross-functional teams” these
people will acquire the required knowledge and skills that are important for building quality in their
IT system and gathering information necessary to establish confidence that the pursued business
value can be achieved. It is a 3-day training course with a 1-hour exam.
Performing QA & testing activities in an organization requires a wide variety of knowledge and skills.
The training course “TMAP®: High-performance quality engineering” enables professionals to
perform these operational activities. It is a 3-day training course with an exam of 1.5 hours.
Organizing QA & testing requires orchestrating, arranging, planning, preparing and controlling the
activities. The training course “TMAP®: Organizing built-in quality at scale” enables
professionals that are responsible for organizing QA & testing to acquire the necessary knowledge
and skills to enable teams to achieve this. It is a 3-day training course with an exam of 1.5 hours.

Accreditation of training providers

Training providers that want to prepare candidates for the exam will need to acquire accreditation
from iSQI. For more information, please contact [email protected]

Public. Copyright © 2023 Sogeti. All rights reserved 9

 TMAP: Quality Engineering for SAP – syllabus

Literature

Exam literature:
▪ The TMAP book “Quality for DevOps teams” (ISBN 978-90-75414-89-9), available on
www.ict-books.com and other bookstores, both in paper and ePub version.
▪ TMAP glossary: https://www.TMAP.net/page/tmap-glossary-online.
▪ Descriptions in chapters 5, 6 and 7 in this syllabus, based on building blocks of www.TMAP.net.
Note: for the exam, texts in this syllabus supersede texts on the website.

Additional literature:
▪ The TMAP body of knowledge website – www.TMAP.net
▪ More info about SAP - https://www.sap.com/about/company/what-is-sap.html.
▪ SAP free tutorials with openSAP- https://open.sap.com/
▪ Interesting SAP Blogs - https://blogs.sap.com/
▪ SAP Best Practices - https://rapid.sap.com/bp/

Other additional literature (specifically for trainers to acquire more in-depth knowledge):
▪ The Agile Manifesto – www.agilemanifesto.org
▪ The Scrum Guide – www.scrumguides.org
▪ ISO25010 - www.iso.org/standard/35733.html
▪ Also please refer to the references in the TMAP book Quality for DevOps teams.

Acknowledgements

This syllabus was created by a diverse team. We would like to thank the following people (in no
particular order) for their contributions in writing and reviewing this document:
Sogeti and Capgemini people: Pepijn Paap, Robin Klein, Prabakaran Vaiyanan, Folkwin Kloezen,
Sapna Singh, Jeanine Hoogerbrug, Bob Zandvliet, Bo de Vries, Sankar Sundaram, Leo Janssen,
Martin van Genderen, Guido Nelissen, Tijs Wonders, Marco van Winsen, Rik Marselis, Gerrit Matser,
Shashank Lokhande, Jan Sleutjes, Stefan Gerstner, Andreas Holm, Kaushik Dutta, Tomasz
Furmaniuk, Agnieszka Flis, Roman Sudol, Aleksandra Trzcionka, Ayat Fazil, Chetan S Jadhav, Kisan
Shirke, Mika Jauhiainen, Patrick Langeveld, Ralf van der Ven, Adryan Bikker, Ankur hadke, Appie
Pries, Bo Zinkstok, Christy Brouwer, Clemens van der Molen, Jeyantha van der Plas Kathiravelu,
Manoj Kumar, Narmadha, Kumarasamy, Omkar Madhav Khatavkar, Shanna Maassen, Tim Oosthoek,
Timo de Groot, Wessel van der Kaaij, Parimal Singh, Chetan Jadhav, Ashok Jangam, Kanchan
Kumari, Shailly Suxena, Wouter Boekenstijn, Eric Belt.
SAP people: Monica Hostiuc, Raja Spaeth.
iSQI people: Stephan Goericke, Erika Paasche, Valida Saronjic.
TMAP Special Interest Group members: Mohit Mantri, Gilbert Smulders, Philippe Bourdeau.

Public. Copyright © 2023 Sogeti. All rights reserved 10

 TMAP: Quality Engineering for SAP – syllabus

1. Session 1

The chapters 1 through 4 describe the learning objectives for this training course and certification.
At the end of each section is a reference to the relevant literature.
The “book” that is referenced is the TMAP book “Quality for DevOps teams” (3rd edition 2022).
References to “syllabus” refer to chapters 5 through 7 of this syllabus.

ERP systems (LO01; K2)

Enterprise Resource Planning (ERP) systems are software tools (often large and complex) that
support organizations in their business processes. They manage enterprise data related to, for
example, supply chain management, production, inventory management, procurement, sales,
accounting, and human resource management. The focus of this training is to support business
users, maintenance - and operations people during acceptance, implementation and eventual usage
of this type of IT systems.
Instead of offering a solution for one department or one business activity, ERP systems are generally
used throughout the organization. They are connected to one overarching enterprise database which
contains the organization’s master data, configurational data and transactional data. Furthermore,
ERP systems require organizations to standardize their processes and use more common ways of
working, as the software is designed with specific end-to-end processes in mind. For this training
course, there are five ways of distinguishing between ERP systems and other IT-solutions, namely:
size of investment, imposed process streamlining, high complexity, ‘configuration’ instead of
‘programming’ and the test varieties that are generally involved.

The candidate understands what ERP systems are used for.

The candidate understands how ERP systems differ from other IT solutions.

Syllabus: section 5.1.

What is SAP (LO02; K1)

SAP SE is the official name of the German multinational software company based in Walldorf, Baden-
Württemberg. This company, hereafter referred to as SAP®, provides Enterprise Resource Planning
(ERP) solutions and services.
At the moment of creation of this syllabus (Q2 2023) the latest business suite is called ‘SAP
S/4HANA®’.
An SAP implementation consists of modules, which support transactions to execute key business
processes.

The candidate recalls how SAP supports all core business processes and which technologies it can
include.

Syllabus: section 5.2.

Public. Copyright © 2023 Sogeti. All rights reserved 11

 TMAP: Quality Engineering for SAP – syllabus

SAP main flows (LO03; K2)

SAP solutions include several modules, which support transactions to execute core business
processes (examples of modules are described in section 5.2).

In general, these modules are represented in 4 SAP main flows:

• Lead-to-Cash (Lead, Opportunity, Quote, Sales Order, Fulfillment, Invoice)
• Source-to-Pay (Sourcing, Contracting, Procurement, Payment, Analytics)
• Recruit-to-Retire (Plan, Staff, Onboard, Work, Travel, Pay & Close)
• Design-to-Operate (Design, Planning, Production, Logistics, Operation)

The candidate understands the purpose of the SAP main flows and SAP modules.

Syllabus: sections 5.2 & 5.3.

Other SAP solutions (LO04; K1)

Besides the SAP modules, discussed in LO03, SAP also offers many other solutions for its customers.
These solutions are not focused on critical business processes, but they are becoming more
frequently implemented for SAP customers. We introduce a set of the most commonly used
solutions, keep in mind this is not the complete list of SAP Solutions.

The candidate recalls other SAP solutions and SAP Fiori.

Syllabus: section 5.4.

IT delivery models for SAP (LO05; K2)

An IT delivery model is a conceptual framework which supports a software development process and
describes all assets and competencies. In SAP projects we distinguish three mainly used IT delivery
models: V-model based Sequential IT delivery, Scrum-based High-performance IT delivery and
Demand/Supply model based Hybrid IT delivery.

The candidate understands the different IT delivery models for SAP.

The candidate understands how to move towards the Demand/Supply Model from a standard V-
model approach.

Book: chapter 7 introduction, section 7.1, chapter 8 introduction, section 8.2, chapter 9
introduction, section 9.1, chapter 10 introduction and section 10.1.
Syllabus: section 5.5.

Public. Copyright © 2023 Sogeti. All rights reserved 12

 TMAP: Quality Engineering for SAP – syllabus

Introduction to Quality Engineering & Testing (LO06; K2)

Quality Engineering is about team members and their stakeholders taking joint responsibility to
continuously deliver IT systems with the right quality at the right moment. With a focus on building
quality from the start, testing will demonstrate if the quality is at the expected level, instead of
trying to find all problems that resulted from a lack of quality focus and fix them at the end. With
ERP systems such as SAP, people often think the quality will be OK because it is supplied by an
established vendor. But even the highest quality software has to be integrated with the specific
business processes of an organization and the quality of this implementation also has to be assured
and tested to establish the confidence that it will deliver the pursued business value.

TMAP distinguishes twenty QA & Testing topics that describe quality engineering activities.

The candidate knows the definitions of quality, quality engineering and testing.

The candidate understands that quality engineering focuses on built-in quality.

The candidate understands that the main goal of testing is to supply information about quality and
related risks to establish confidence in the pursued business value.

Book: section 1.2 (including 1.2.1 of the 3rd edition), chapter 5 introduction, chapter 11.

Business value and the VOICE model (LO07; K2)

Today’s organizations expect that their IT systems will enable them to generate business value.
IT teams and their stakeholders use the VOICE model to establish the level of confidence that the
pursued business value can be achieved with the IT system.
The candidate understands that delivering business value is the goal of IT delivery activities.

The candidate can give a description of the VOICE model and knows that it is an acronym of Value,
Objectives, Indicators, Confidence and Experience.

Book: chapter 3.

Introduction to built-in quality (LO08; K2)

Built-in quality means that the proper quality measures are selected and implemented to deliver the
right level of quality at the right moment and to achieve the business value. When looking at
quality, it is important to look at both functional and non-functional quality characteristics.

The candidate understands that built-in quality relates to the quality of products, processes and
people.

The candidate knows the difference between functional and non-functional quality characteristics.

Book: chapter 1 introduction, sections 1.2.1 (of 3rd edition), A.1, A.2, A.3 and A.4.

Public. Copyright © 2023 Sogeti. All rights reserved 13

 TMAP: Quality Engineering for SAP – syllabus

Test Design – Introduction (LO17; K3)

Creating tests and executing them may sound easy, but structured testing requires careful
consideration. We use the term “test design” for the complex of activities to create tests, even
though some approaches to testing have no actual up-front design.
The candidate can distinguish the two ways of creating and executing tests: coverage-based and
experience-based test design. The candidate understands why these should always be combined.
The candidate understands the basics of test design and the four coverage groups of coverage-
based test design techniques.
The candidate knows what a test case consists of (input & action, expected results, actual results,
pass/fail, observations) and can create test cases for a given test situation.

Book: chapters 30 and 43; section 45.1.

Public. Copyright © 2023 Sogeti. All rights reserved 14

 TMAP: Quality Engineering for SAP – syllabus

2. Session 2

The SAP project (LO11; K2)

Implementing a new IT system can be a daunting task for any organization, but when that system is
an SAP system, the process becomes even more complex.

One of the biggest differences between an SAP IT project and a “normal” IT project is the level of
expertise and experience required. Because SAP is a complex and customizable system, it requires
teams with specific SAP knowledge and experience (additional to their business process knowledge)
to implement it effectively. Another key difference is the impact that implementing an SAP system
can have on an organization’s operations. Because SAP is designed to integrate with a wide range of
business processes, it can have a significant impact on how an organization operates and how it
interacts with its customers and suppliers. This means that careful planning and coordination are
required to ensure that the implementation goes smoothly, and that the organization can continue
operating during the transition.
Typically, one of the success factors for an SAP implementation project is that the project is
considered as a business transformation project for the customer where IT (SAP in this case) is an
enabler of the business transformation. The SAP implementation should not be considered as just an
SAP IT project with main focus on “technical implementation” of the processes. More important is
the impact of the change to the business processes of the organization.
There are several types of SAP implementations, we distinguish 8 examples of types of SAP projects.

The candidate understands what is important when initiating an SAP IT project and what types of
SAP projects exist.

Syllabus: section 5.6.

SAP Activate (LO12; K1)

The SAP Activate methodology is a modular and agile framework which helps project teams to
accomplish their tasks to deliver an SAP system. SAP Activate provides a clear guided methodology
to deploy, adopt and extend new capabilities across organizations. Start fast, build smart, and run
simple, while continuously innovating with SAP Activate.

The candidate recalls the basic features of the different SAP Activate methodology phases and test
varieties.

Syllabus: section 5.7.

Public. Copyright © 2023 Sogeti. All rights reserved 15

 TMAP: Quality Engineering for SAP – syllabus

SAP Quality Risk Analysis (LO13; K3)

The time available for testing is limited; not everything can be tested with equal thoroughness and
intensity, the number of possible tests in an SAP system is simply too large. Teams do not want to
spend too much time on testing ‘Standard SAP’ processes. ‘Standard SAP’ processes are processes
which are generally used by many organizations amongst different industries. Because many
organizations use these processes, the risk of anomalies are low. Teams should use the available
testing time and effort on the high-risk areas first, which are mainly new additions and changes, for
which progression testing is organized. The ‘Standard SAP’ steps and unchanged parts will be
incorporated in the end-to-end regression testing.
During the Quality Risks Analysis, the scope of the change or project (regardless if it is an
implementation, a rollout or an upgrade) is important. Local requirements, legal requirements,
language requirements etc., should be included in the Quality Risk analysis.
Risk based testing means choices must be made, resulting in a risk-based test strategy. The starting
point is: an SAP system must function in such way that unacceptable quality risks have been
covered. Where the delivery of a certain SAP process brings along many quality risks, thorough
testing is needed. At the other end of the spectrum, you should decide: ‘no risk, no test’ (where
TMAP adds ‘no implementation’, because no risk actually means nobody has a problem if it fails,
therefore nobody needs it, thus the feature should not be implemented at all).
The candidate can contribute to performing an SAP Quality Risk Analysis.

Book: chapter 26, section 5.2.1 & 5.2.2.

Syllabus: section 6.4.

SAP Test Strategy (LO14; K2)

The SAP Test Strategy contains the information about quality measures and activities to be
performed and organized to establish grip and control on the SAP landscape. It indicates all relevant
subjects to be covered for the SAP project and the support organization. The SAP test strategy is
based on a quality risk analysis to establish the intensity of the quality measures that will be
applied.

An SAP Test Strategy is part of the SAP Project and should not act independently. It must be within
SAP project boundaries and methodologies. For different types of SAP Projects (implementation,
rollout or an upgrade) a different SAP Test Strategy can be applicable.

The candidate understands which information is necessary to create an SAP Test Strategy.

Book: section 15.4.3, section 26.5 and 26.6.

Syllabus: section 6.5.

Public. Copyright © 2023 Sogeti. All rights reserved 16

 TMAP: Quality Engineering for SAP – syllabus

SAP Test Plan (LO15; K2)

A test plan is the description of the general structure and the choices with respect to the tests to be
executed and the way to supply information.

A test schedule is a detailed overview of test activities to be performed and executed in a specific
sequence and time.
The candidate understands the generic structure of an SAP Test Plan.
The candidate understands the difference between SAP Test Plan and SAP Test Schedule.

Book: chapter 11, section 15.4.3.

Syllabus: section 6.6

Quality gates (LO16; K1)

A quality gate is a milestone in an IT project that requires predefined criteria to be met before the
project can proceed to a next phase. Quality gates are commonly used throughout the IT delivery
process to provide information whether a delivery complies with quality expectations.

In an SAP project, quality gates are used to organize the handover between Solutioning teams, the
System integrator, the (business) testers and other internal and external parties when starting a
different testing phase in the project.

The candidate recalls the use of quality gates in an SAP project.

Book: section 10.1.

Syllabus: section 6.7.

Test Design – Equivalence Partitioning (LO18; K3)

In the application of equivalence classes, the entire value range of a parameter is partitioned into
classes. In a specific class, the system behavior is similar (equivalent) for every value of the
parameter.

The candidate can apply Equivalence Partitioning (EP) to a given test basis.

Book: section 46.5.

Public. Copyright © 2023 Sogeti. All rights reserved 17

 TMAP: Quality Engineering for SAP – syllabus

Test Design- Boundary Value Analysis (LO19; K3)

Boundary Value Analysis is a test design technique. This technique is based on the fact that around
a boundary in the value range of a variable, there is a higher risk of faults in a system.

The candidate understands the difference between two-value -, three-value – and four-value
Boundary Value Analysis.
The candidate can apply Boundary Value Analysis (BVA) to a given test basis.

Book: section 46.5.

Public. Copyright © 2023 Sogeti. All rights reserved 18

 TMAP: Quality Engineering for SAP – syllabus

3. Session 3

Stakeholder management in SAP projects (LO09; K3)

Stakeholders are defined as “anyone with viable interest in the business value delivered by the
team, at all levels in the organization and even outside the organization”.

Stakeholder management is about how to involve, enthuse, and engage the stakeholders that
matter.

In SAP projects (as in any other ERP project), stakeholder management is even more important
than in non-SAP projects. This is because of the complexity and major organizational impact of SAP
projects. SAP projects often impact multiple parts of the organization. Aligning the stakeholders
from all parts of the organization is crucial for the success of an SAP project.

The candidate can select the relevant stakeholders and determine their information needs in a
specific situation.

Book: sections 3.3, 5.2, 5.4.

Syllabus: section 6.1.

ARCI matrix for stakeholder responsibilities (LO10; K3)

An ARCI-matrix contains a list of deliverables and/or activities on the rows of the matrix and
specifies the people involved (stakeholders) in the columns. For every deliverable/activity the table
shows per role or person in what way they are involved, which can be Accountable, Responsible,
Consulted, or Informed.

The candidate understands the four types of involvement.

The candidate can classify stakeholders in an ARCI-matrix.

Book: sections 3.3, 5.2, 5.4 and the template of www.TMAP.net.

Syllabus: section 6.2.

SAP Authorizations managed with RBP (LO20; K2)

Role-Based Permissions (RBP) manage the permissions in SAP suites. RBP controls access to the
applications, and controls what users can see and do. RBP is a suite-wide authorization concept
which applies to most SAP modules. The main elements in RBP are permission groups and
permission roles that allow SAP users access to specific parts of the application. The responsibility
for setup, maintenance and managing authorizations lies with the SAP Basis team or Governance,
Risk, Compliance & Security.
The candidate understands the basics of authorizations and Role Based Permissions for SAP.

Syllabus: section 5.8.

Public. Copyright © 2023 Sogeti. All rights reserved 19

 TMAP: Quality Engineering for SAP – syllabus

SAP End-to-end testing - vertical and horizontal (LO21; K2)

SAP systems today are rarely standalone and are at the center of an increasingly large and complex
network of both internal applications and business partner systems. Therefore, SAP end-to-end
business processes can become very complex.
Integrations play a critical role in the SAP landscape and architecture. A basic understanding of
integration is needed to understand end-to-end flows in SAP systems.
During the different test varieties, the focus is moving from stand-alone functionality and individual
processes, solution trains and modules (Verticals) towards complex end-to-end scenarios
overarching SAP modules, SAP systems and non-SAP systems (Horizontals).
The candidate understands the importance and challenges of SAP end-to-end testing.
The candidate understands the difference between vertical and horizontal testing in SAP.

Book: chapter 3, chapter 33, chapter 37 introduction, section 37.5.1.

Syllabus: section 7.7.

Test data (management) in SAP (LO22; K2)

To start testing any SAP system, it is a prerequisite to have test data identified and in place.
Practical experience shows that test data preparation is a time-consuming activity of software
testing, this is especially true for SAP projects. In SAP we use both regular test data (for testing
specific testcases like creating a sales order) and master data (that needs to be set up in advance to
make testing possible).
Master data tends to be relatively static. Examples of master data in SAP include the information in
business partner records. This is all the static data about suppliers and customers. Master data can
also determine the behavior of SAP (e.g. condition records). An example of master data is employee
master data with information like employee name and social security number.
Selecting and using test data in SAP can be very time-consuming for the following reasons: Complex
data structures, data duplication, data privacy, data consistency, lack of standardization, and
specific data & systems settings.
The candidate understands the structure of SAP test data and master data.
The candidate understands the challenges of selecting and using proper test data in SAP systems.

Book: chapter 31.

Syllabus: section 7.1.

SAP organizational change management (LO23; K2)

Organizational Change Management (OCM) is a discipline that supports organizations and their
employees in smoothly and successfully introducing an intended change into their ways of working.
Implementing a change within an organization is often complex and has an impact on people’s
everyday work. Therefore, consciously thinking about how to introduce the change and guiding
organizations and their employees towards it is very important.
The candidate understands the general aim of Organizational Change Management and which
elements are frequently used to achieve successful change implementation.

Syllabus: section 6.3.

Public. Copyright © 2023 Sogeti. All rights reserved 20

 TMAP: Quality Engineering for SAP – syllabus

SAP test execution (LO24; K2)

Test execution is the execution of tests by running the system under test. Test execution obtains the
actual results that can be compared with the expected results to determine whether the tests have
passed or failed. This is part of dynamic testing.
The candidate understands what test execution is and how test execution is done in SAP projects
with one or more test varieties.

Book: section 5.5, chapters 33 and 34.

Syllabus: section 6.8.

Test Design – Path Testing (LO26; K3)

Path testing aims to demonstrate that all combinations of N consecutive paths in a process flow are
covered. A path in this context consists of all steps between a decision point and the next decision
point, or between the start and the first decision point, or between the last decision point and the
end.

The candidate can apply the coverage type “Path Coverage” with Test Depth Level 1 (TDL-1) and the
test design technique “Process Cycle Test” to a given test basis.

Book: section 46.3, template path testing on www.TMAP.net .

Public. Copyright © 2023 Sogeti. All rights reserved 21

 TMAP: Quality Engineering for SAP – syllabus

4. Session 4

SAP Anomaly management (LO27; K2)

An anomaly is a difference between the expected behavior and the actual outcome of a test. This is
registered so that the cause can be analyzed and resolved.

The process of identifying, investigating, and resolving anomalies is known as anomaly

management. An anomaly must be investigated, and when the cause of the problem is found, it can
be fixed.
The candidate understands the anomaly management process.

Book: chapter 18.

Syllabus: section 7.4.

Indicators and Test Reporting (LO25; K2)

To measure whether the objectives (from the VOICE model) are achieved, one or more indicators
per objective are defined. These indicators are measured by means of data collection and data
analysis. Measuring is generally done by testing, but other quality measurement activities are also
used.
Testing is about providing different levels of information. Usually there are multiple stakeholders for
the information that the team generates based on their quality engineering activities.

The candidate is aware of relevant indicators to measure whether objectives are achieved.

The candidate can explain relevant information for dashboards & reports.

Book: chapter 4, section 5.4, chapter 19 introduction, sections 19.1 and 19.2.

Continuous everything (LO28; K1)

To implement business processes with their supporting IT systems that deliver business value, IT
teams need a continual focus on building in quality by applying the appropriate quality measures
throughout all IT delivery stages. Continuous quality engineering is about continuous integration and
continuous delivery supported by continuous testing. Also, it includes continuous improvement of
products, processes and people.

The candidate recalls that built-in quality is the goal of continuous quality engineering.

Book: sections 1.2 and 1.2.1 (not 1.2.2 and 1.2.3) and section 6.2.

Public. Copyright © 2023 Sogeti. All rights reserved 22

 TMAP: Quality Engineering for SAP – syllabus

SAP and CI/CD pipelines (LO29; K1)

Modern high-performance IT delivery teams (such as in Scrum or DevOps) aim to achieve

continuous integration (CI) and continuous delivery (CD). This means that changes are integrated
with the existing system as early and often as possible and the system is continuously kept in a
state in which it is deployable to the live environment. A CI/CD-pipeline is the set of tools that
supports continuous integration and continuous delivery.

The candidate knows what a CI/CD-pipeline is and how it could be used in SAP implementations.

Book: sections 6.1 and 6.2.

Syllabus: section 7.2.

Test Management Tooling for SAP Projects (LO30; K2)

A test management tool for SAP supports the continuous testing journey of the SAP testing team.
The test management tool should be aligned to support the IT delivery model in use (such as Agile,
Scrum, V-model, and hybrid).
The candidate understands what test management tools can contribute to SAP projects.

Book: chapter 12, section 23.1.2.

Syllabus: section 7.3.

SAP Test Automation & Tooling (LO31; K1)

Because release cycles occur in quick succession of one another, testing can become the bottleneck
when solely relying on manual testing. Spotting problems in software sooner rather than later can
save rework and prevent delays in releasing the software. Automated test execution can support to
meet the timelines.
Test automation for SAP can be defined as: “automatically executing scenarios of realistic business
processes for testing purpose, to get information about the behavior of the application to make
informed decisions on the quality of the SAP system.”
There are 4 different types of test tool capabilities: test control, test design, test execution and test
environment. Test Automation Tooling mainly focuses on test execution even though there are tools
that are part of a platform that spans over all these capabilities that are necessary to successfully
test your SAP environment.
The candidate recalls the possibilities, advantages, and limitations, that Test Automation can bring
to an SAP environment.
The candidate recalls considerations for choosing test automation tooling that adds value in an SAP
environment.

Book: chapter 23 introduction, sections 23.1, 32.1 and 32.2.

Syllabus: section 7.5.

Public. Copyright © 2023 Sogeti. All rights reserved 23

 TMAP: Quality Engineering for SAP – syllabus

SAP Performance Testing (LO33; K1)

The SAP user may experience performance issues during certain business operations, and this will
impact the productivity of the business users. To prevent such issues, SAP performance testing
ensures that all SAP applications are tested adequately to give sufficient information about the
expected user experience during peak load.
The candidate knows what performance testing and its benefits are, including how various types of
performance testing will help to improve the efficiency of business processes.

Book: sections 38.1, 38.2.

Syllabus: 7.6.

Test Design – Exploratory Testing (LO34; K3)

Exploratory testing is the most versatile experience-based approach to testing. It is a structured

approach that is performed by pairs or mobs of testers, who use charters and logs, and end every
exploratory testing session with a debriefing with one or more stakeholders.

The candidate understands the characteristics of exploratory testing and the importance of a test log
and debriefing.

The candidate is able to create and execute a charter for an exploratory testing session and report
the results.

Book: section 36.1; section 47.4, template Exploratory testing charter on www.TMAP.net.

Public. Copyright © 2023 Sogeti. All rights reserved 24

 TMAP: Quality Engineering for SAP – syllabus

5. Description of additional subjects – ERP & SAP

This chapter and the following chapters contain the in-depth descriptions to support learning
objectives that are not based on contents of the book “Quality for DevOps teams”. These additional
subjects are based on information that is available on the TMAP body of knowledge website
(www.TMAP.net).
This chapter contains the general descriptions of ERP systems and of SAP as a predominant example
of ERP systems.
Note: For the exam the descriptions in this chapter supersede any texts on the website, even in case
the website would contain other (more up-to-date) descriptions. This syllabus is updated regularly to
include the latest insights.

ERP systems: Their usage and unique characteristics

Enterprise Resource Planning systems

Many companies worldwide use Enterprise Software which integrates many different software
modules and a centralized database. With this software, organizations can create an Enterprise
Resource Planning (ERP) system, also simply known as an ‘Enterprise System’. Unlike applications
that deal with one separate activity (for example, a payroll system) or department (for example,
Sales), ERP systems combine all kinds of different business processes (like manufacturing and
production, finance and accounting, sales and marketing, and human resources) into one single
software system. This means that an organization that uses an ERP system has a centralized
database to which all kinds of different (sub-)systems are connected. Through these smaller
systems ( ‘Line of Business’ (LoB), ‘Business Areas’ or ‘modules’), management and users can
perform and monitor different business activities (or ‘business processes’) that are needed for an
organization to perform well and make it function as efficiently as possible.
Business Processes are the (often unique) ways in which work activities have been organized to
eventually produce a valuable product or service. They are supported by material, information and
knowledge flows between the participants of the business processes. Such processes belong to
certain functional business areas, for example:
• Manufacturing and/or Production
• Sales and Marketing
• Supply Chain
• Finance and Accounting
• Sourcing and/or Procurement
• Asset Management
• Research and Development (Engineering)
• Human Resources
An example of a business process within ‘Sales’ could be the identification of (potential) customers
and for ‘Human Resources’ it could be the evaluation of an employee’s job performance. An ERP
system keeps track of all these different business processes and enables the organization to work
from centralized data, instead of scattered bits of information.
There are many providers of ERP systems. A well-known provider with a large market share is SAP.
Other familiar global players within this industry are Oracle, Workday, Salesforce, and Microsoft
Dynamics 365. Many other ERP solutions operate on a smaller scale (in specific countries or
regions). Even though this training material focuses on an SAP-context, the product goal and

Public. Copyright © 2023 Sogeti. All rights reserved 25

 TMAP: Quality Engineering for SAP – syllabus

business process orientation of these other software products and providers are in line with one
another, and skills taught in this training course are applicable to these environments as well.

Figure 1 Standard ERP-functionalities

(Source: https://www.deskera.com/blog/frequently-asked-questions-about-erp/ )

ERP systems compared to other IT-solutions

The distinguishing nature of Enterprise Software (or the ERP system) is its organization-wide use
and the large degree of interconnectedness of systems, applications, interfaces, and databases. The
implementation, testing and eventual usage of an ERP system requires a different approach
compared to other IT-solutions.
For this, five general distinctions can be made between an ERP system and different IT-solutions.
Major investment
Although every form of software development has its price tag, the implementation of an ERP
system is a major investment. Depending on the range of the purchased Enterprise Software, it is
common for an organization to spend between fifty thousand and hundreds of millions of dollars in
ERP-software. And besides the investment in ERP-software, elements like hardware, technical
support, overall project management, internal team commitment, external support/consultants, and
training also need to be considered. In other words, the Total Cost of Ownership (TCO) for an ERP-
implementation can become quite high. A survey amongst 181 ERP users showed that 38 percent of
the ERP-projects experienced cost overruns, and they averaged a 66 percent over budget.
Companies are wise to complete a thorough cost-benefit analysis before investing in an ERP system,
because a change towards a different supplier will be very costly afterwards. This investment should
be earned back by lower operational costs and the lack of costs for development and maintenance of
bespoke software.

Public. Copyright © 2023 Sogeti. All rights reserved 26

 TMAP: Quality Engineering for SAP – syllabus

Restricted level of customization

A second difference is the restricted level of customization and the realization that ERP systems
impose processes on the organizations that implement it. Before implementation, companies need to
make a selection in functionalities of the system they wish to use and then map their business
processes to the predefined business processes in the software. Company-specific configurations can
be made, but in general, an ERP system follows the ‘best practice’ processes as set up by the
software supplier which will then be the same for all companies buying and using said software.
Redesigning Enterprise Software to fit an organizations current way of working (and as such
differentiating from the best practices and standards) might lead to higher expenses/
implementation/ maintenance costs. And this will have an impact on scalability and maintainability
and take away the benefits of streamlined processes.
High complexity
Because ERP systems can be used in practically every type of business operation, there is often a
high complexity within the software landscape. The many different interfaces, shared data,
connections to cloud and on-premises environments, supplier/customer websites and third-party
systems that have been bought from outside the larger ERP-solution, can create a tangled and
inaccessible IT-architecture. This third ERP-characteristic opposed to other IT-products demands
many kinds of knowledge fields and skills. Nevertheless, this (inter-)connectedness of the ERP
system will benefit the organization in the long run due to its efficiency, standardization, and real-
time insights.
Configuration oriented
The fourth general distinction between ERP systems and other IT-solutions is related to the way
ERP-suppliers create and sell/distribute their products. As said before, Enterprise Software is
developed beforehand and is then sold to interested organizations as a largely ‘off-the-shelf’ or ‘on
demand’-type of product. Because of this, the IT-development team at the organization that buys
the software is less occupied with programming/coding, and more with configurations, workflows,
data, and authorizations. The more technical aspects of the software have been dealt with by the
developers of the ERP supplier and although customized changes are possible, any desired
modifications generally go through requests back towards the system integrator or software
supplier. A change request in SAP is called RICEFW.
Less conventional unit tests
Zooming in more on ERP Testing, the fifth difference connects to the previous notion of ERP systems
being sold relatively ‘ready-made’. Because of this, there are less conventional ‘unit tests’ in which a
developer and tester will, for example, check code and/or an initial small functionality. Testing within
an ERP system is more often concerned with functionality, proper (flow) configuration and data
handling. As such, testing of an ERP system deals more with process checks, interface testing,
acceptance tests, output validations and end-to-end testing. This does not mean that the test
variety ‘unit testing’ does not exist for ERP Testing, however, its content and aim generally differs to
unit tests within other IT-product development processes.
Sources:

Laudon, Kenneth C. Management Information Systems: Managing the Digital Firm (Global Edition). Pearson
Education Limited (Harlow), 2022. P. 73, 82, 372 and 388.

Sumner, Mary. Enterprise Resource Planning (Pearson New International Edition). Pearson Education Limited
(Harlow), 2014. P. 1-2 and 11.

SAP. “SAP History: Building on a track record of innovation. The Early Years.” Accessed September 23, 2022.
https://www.sap.com/about/company/history/1972-1980.html

Public. Copyright © 2023 Sogeti. All rights reserved 27

 TMAP: Quality Engineering for SAP – syllabus

What is SAP®?

SAP stands for System Analysis Program Development (Systemanalyse und Programmentwicklung).
As a company, SAP has been a part of the ERP-evolution (which started in the 1960s) since very
early on. In 1972, the SAP founders set out to “create software that integrates all business
processes and makes data available in real-time” (SAP History).
SAP is the world leader in enterprise applications in terms of software and software related service
revenue. SAP is supporting all kinds of industries and various sizes of organizations. SAP helps them
to improve profitability, grow sustainably and stay ahead of the competition in the market. SAP
relies on their implementation partners as a system integrator to serve their customers. SAP
supports their partners during and after the implementation.
SAP systems have been created in multiple generations. At the moment of creation of this syllabus
(Q2 2023), the latest (fourth) generation is SAP S/4HANA® which means “Business Suite 4 – High
performance, Analytical Appliance”.

An SAP implementation consists of modules (Line of Business (LoB) and Business Areas), which
support transactions to execute key business processes, such as:
• Financial Accounting (FI)
• Financial Supply Chain Management (FSCM)
• Controlling (CO)
• Materials Management (MM)
• Sales and Distribution (SD)
• Logistics Execution (LE)
• Production Planning (PP)
• Quality Management (QM)
• Plant Maintenance (PM)
• Project System (PS)
• Human Resources (HR)
And many more.

Apart from ERP software the SAP company supports:

• Database software and technology (particularly its own brands)
• Cloud engineered systems, and other ERP software products, such as human capital
management (HCM) software
• Customer relationship management (CRM) software (also known as customer experience)
• Enterprise performance management (EPM) software
• Product lifecycle management (PLM) software
• Supplier relationship management (SRM) software
• Supply chain management (SCM) software
• Business technology platform (BTP) software
• Programming environment SAP AppGyver for business
And many more.

SAP supports different types of deployments:

• On-premises: SAP is deployed internally by the organization. Located on their own servers
and managed by the organization.
• Cloud: where the organizations that use SAP do not manage their own data centers but
deploy their solution in the cloud, likeSAP Private Cloud or a Public Cloud (AWS, Azure,
Google).
• Hybrid: combination of On-premises and Cloud to provide flexible options to organizations.

Public. Copyright © 2023 Sogeti. All rights reserved 28

 TMAP: Quality Engineering for SAP – syllabus

We have covered only the high-level basics about SAP in this chapter, there is a lot more to know
about SAP but that is beyond the scope of this training. For more info about SAP, please refer to the
following sources:
• More info about SAP can be found on the SAP website:
https://www.sap.com/about/company/what-is-sap.html.
• To learn more about the latest developments at SAP, refer to the SAP Blogs:
https://blogs.sap.com/.
• SAP free tutorials with openSAP can be found here: https://open.sap.com/.

Public. Copyright © 2023 Sogeti. All rights reserved 29

 TMAP: Quality Engineering for SAP – syllabus

SAP main flows and modules

In general, the SAP modules (see section 5.2) are represented in four SAP main flows:
• Lead-to-Cash (Lead, Opportunity, Quote, Sales Order, Fulfillment, Invoice)
• Source-to-Pay (Sourcing, Contracting, Procurement, Payment, Analytics)
• Recruit-to-Retire (Plan, Staff, Onboard, Work, Travel, Pay & Close)
• Design-to-Operate (Design, Planning, Production, Logistics, Operation)

Figure: SAP main flows

The main flows of SAP consist of business functions that are supported by the SAP modules.
Although these are the 4 main flows, the implementation and naming of these flows can differ per
organization.

SAP Financial Management is a combination of two modules (Line of Business), i.e. Finance
Accounting (FI) and Controlling (CO). Under Finance in SAP and at an enterprise level, the following
modules take part:
FI – Finance
CO – Controlling
IM – Investment Management
TR – Treasury
EC – Enterprise Controlling

SAP FI (Financial Accounting) is accountable for tracking the flow of financial data across the
organization in a controlled manner and integrating all the information for effective strategic
decision-making.
SAP CO (Controlling) module facilitates coordinating, monitoring, and optimizing all the processes in
an organization. It controls the business flow in an organization. This module helps in analyzing the
actual figures with the planned data and in planning business strategies.
Some important financial elements managed in CO are:
• Cost elements
• Revenue elements

Sales & Distribution Management (SD) is one of the most important modules in SAP. It has a
high level of integration complexity. SAP SD is used by organizations to support sales and
distribution activities of products and services, starting from enquiry (lead) to order, and then
ending with delivery.

Public. Copyright © 2023 Sogeti. All rights reserved 30

 TMAP: Quality Engineering for SAP – syllabus

In all these processes, multiple modules are involved such as FI (Finance Accounting), CO
(Controlling), MM (Material Management), PP (Production Planning), LE (Logistics Execution), etc.,
which shows the complexity of the integration involved.

Material Management (MM) deals with movement of materials via other modules like logistics,
supply chain management, sales and delivery, warehouse management, production, and planning.

Production Planning (PP) deals with planning processes, such as capacity planning, material
planning, execution of production order, bill of material and goods movement. SAP PP module
handles the master data required for Bill of Materials (BOMs) activity, work center and routing, and
keeps it in a separate component.

Quality Management (QM) is an integral part of logistic management, and it is used to perform
quality functions such as quality planning, quality assurance, and quality control, at various stages
such as incoming material stage, in-process manufacturing process stage, and after production as
well.
QM is integrated with other SAP modules like SAP Material Management (MM), Production Planning
(PP), and Plant Maintenance (PM).

Plant Maintenance (PM) is a software product that manages all maintenance activities in an
organization. Plant Maintenance module consists of key activities to include inspection, notifications,
corrective and preventive maintenance, repairs, and other measures to maintain an ideal technical
system.
Using SAP PM, you can perform automatic repairs and facilitate maintenance requests in an
organization. It allows you to record problems in SAP system, plan labor and material activities, and
to record and settle the cost.

Project Systems (PS) performs project and portfolio management. It helps you to manage the
project life cycle starting from structuring to planning, execution, until the project completion.
Project system is closely integrated with other SAP modules like logistics, material management,
Sales and Distribution, Plant Maintenance, and Production planning module.

Human Resources (HR) also known as Human Capital Management (SAP HCM), SAP Human
Resource Management System (SAP HRMS) or SAP Human Experience Management (SAP HXM).
Human capital management products from SAP can help your organization hire and retain the right
people, manage the work environment, streamline HR processes, ensure legal compliance, and
create a people-centric organization.

Master Data Governance (MDG) The SAP Master Data Governance application provides ready-to-
run, domain-specific master data governance, so you can locally own and consolidate or centrally
create, change, and distribute master data across your enterprise system landscape, like business
partners, material master data and financial master data.
Master Data Governance is very important within an SAP landscape as it connects to all other
available modules by providing relevant and necessary data elements.

Industry-specific solutions
Based on the main flows and modules, SAP offers a great number of industry-specific solutions that
contain additional industry-specific functionality. Examples are SAP Retail (for retail organizations),
SAP ISU (for utility organizations), SAP Oil, Gas & energy (for energy companies) and more.

Public. Copyright © 2023 Sogeti. All rights reserved 31

 TMAP: Quality Engineering for SAP – syllabus

Other SAP solutions

Besides the SAP modules, discussed in section 5.3, SAP also offers many other solutions for its
customers. These solutions are not focused on critical business processes but are becoming more
frequently implemented. We introduce a set of the more often used solutions, keep in mind this is
not the complete list of SAP Solutions.
A selection of SAP solutions:

➢ SAP Ariba
➢ SAP Concur
➢ SAP Fieldglass
➢ SAP Customer Experience
➢ SAP HR/ SuccessFactors
➢ SAP Hybris
➢ SAP IBP

Below we briefly describe each solution and at the end we describe the user interface Fiori.

SAP Ariba
SAP Ariba is a cloud-based Procurement solution to perform business transactions on a single
platform. It can be easily integrated with other SAP ERP products without using middleware and can
be customized as per business requirements. SAP Ariba provides out of box functionality to buyers
and suppliers to do business and to get maximum benefits from procurement management.
It improves the overall vendor management system of an organization by providing less costly ways
of procurement and making business simple. SAP Ariba acts as supply chain, procurement service to
do business globally. SAP Ariba digitally transforms your supply chain, procurement and contract
management process.

SAP Concur
SAP Concur is an online and mobile solution for Travel and Expense management. It includes
corporate travel booking, expense report automation, reimbursement, audit, business intelligence
and corporate card integration. It is offered in multiple editions: Small Business, Standard,
Professional, Premium.

SAP Fieldglass
SAP Fieldglass provides a cloud-based Vendor Management System (VMS) to manage contingent
workforce and services procurement programs. The SAP Fieldglass Vendor Management System
(VMS) gives the customer total visibility into global external workforce to reduce costs, enforce
compliance, improve worker and supplier quality, and increase program efficiencies.

SAP Customer Experience

SAP Customer Experience (CX) helps businesses around to move beyond legacy customer
relationship management to a modern-day customer experience. The customer experience is how
interactions with the brand or product make customers feel. A customer can be a business (B2B) or
a person (B2C) the approach is the same. SAP Customer Experience aims for a positive experience
for all customers.

Public. Copyright © 2023 Sogeti. All rights reserved 32

 TMAP: Quality Engineering for SAP – syllabus

SAP HR/SuccessFactors
SAP HR or SAP SuccessFactors focuses on what employees need to be their best. It shifts from
human capital management (HCM), its processes, steps, and procedures and moves to
individualized experiences designed to keep employees happy, productive, engaged, and improving.
SAP HR/SuccessFactors provides:
• Core HR and Payroll
• Time and attendance
• Recruiting and onboarding
• Learning and Development
• Performance and Compensation
• Workforce planning and Analytics

SAP Hybris
SAP Hybris is a cloud-based e-commerce platform solution for B2B and B2C. Hybris’ omnichannel e-
commerce capabilities are deeply integrated into the SAP cloud ecosystem, giving sellers the
enhanced data and tools to optimize margins and drive customer loyalty.
SAP has integrated its own backend system – SAP CRM and SAP ERP with the Hybris solution, so
any organization that has SAP ERP or SAP CRM implemented can easily move to the SAP Hybris
solution.

SAP IBP
SAP Integrated Business Planning for Supply Chain (SAP IBP) features supply chain analytics, what-
if simulations, alerts, and more to help improve responsiveness. It is a cloud-based solution that
combines sales and operations planning (S&OP), forecasting and demand, response and supply,
demand-driven replenishment, and inventory planning.

SAP Fiori®
SAP Fiori is not a solution for a business process but a solution for a more user-friendly Graphical
User Interface (GUI). SAP Fiori is an update to the SAP user interface where the focus is no longer
on huge amounts of functionality but rather a comfortable user experience.

Each SAP Fiori application is built around the user, rather than the function. As a result, the screens
are very simple and uncluttered. A key goal of any SAP Fiori application is to ensure that a user can
complete a task with as few clicks as possible.
In the old SAP GUI, transactions and transaction codes are required, in SAP Fiori the transactions
are replaced by and embedded in tiles. SAP Fiori tiles are shown based on the user’s role.

Public. Copyright © 2023 Sogeti. All rights reserved 33

 TMAP: Quality Engineering for SAP – syllabus

IT delivery models for SAP

In the last 20 years, most SAP projects used a sequential IT delivery model (especially the V-
model). In current SAP projects we see the shift towards a Demand/Supply Model where parts of the
Agile way of working are implemented in SAP projects (For an explanation of the IT delivery models
see chapter 7 of the TMAP book Quality for DevOps teams).
In this section we first describe how to transition from a sequential to a hybrid IT delivery model.
Next, we describe good practices of the Agile mindset that can be implemented in SAP projects.

Working towards a hybrid model

Many organizations with SAP projects that want to benefit from the Agile way of working will actually
need to implement a hybrid IT delivery model. When an SAP project wants to move from a V-model
approach towards a hybrid model (especially the Demand/Supply model) it is advisable to start
small. SAP projects are usually major in size and impact and consist of multiple teams working on
the same solution. For this change in way of working, start with a minimum viable product (MVP),
for example for the Finance Module, and after this approach has been proven successful, expand to
the core value chain.

Begin a transition towards a hybrid model by adding smaller custom functionality to a sprint and
start expanding from there. It is important to consider that if a team is working on an object in a
sprint that another team cannot work on the same object. Coordinating which team is working on a
specific SAP object and managing the integration of these objects is crucial when multiple teams are
working in a hybrid model. The system integration test (SIT) to verify the quality of the integration
of multiple deliverables is a good method to guarantee the quality of these releases.

Demand/Supply model

Figure: Demand/supply model

Public. Copyright © 2023 Sogeti. All rights reserved 34

 TMAP: Quality Engineering for SAP – syllabus

The Business is the Demand side ➔ the business demands new changes, requirements, legislation
etc. This is the non-agile part of the hybrid model. Then the business needs are translated in
requirements / Epics / Feature / User Stories and handed over to the Development team(s).
The IT delivery team is the Supply side ➔ the development team(s) will transform the demands into
useful (business) processes using design / coding / Unit Test(UT) and System Test(ST) in an agile
way of working. After successful UT / ST (teams focused UT and ST testing) the solution is handed
over back to the business for final integration, acceptance and regression test before it can be
deployed to production.

Agile good practices in SAP

An overview of the Agile good practices that are commonly implemented in SAP projects:

Delivering functionality in sprints; (Non-)functional requirements for SAP products can be

delivered in smaller iteration than the waterfall release schedule. By using sprints for each Solution
Train, the project becomes more manageable. Testing these sprints will require regression testing
preferably by using Test Automation each sprint to guarantee the quality of each sprint. During each
sprint the scope of the (automated) regression test set can be expanded.

Create user stories; Splitting up (non)-functional requirements into user stories is required for the
use of sprints in the project. This helps in making the project scope more manageable. Consider to
focus the user stories within the Solution Train on the (non-)functional requirements within that
Solution Train and have a separate set of user stories to focus on the end-to-end solution covering
multiple Solution Trains.

Create a backlog for user stories; Having a backlog for the user stories allows the team to
combine related functionalities in the same sprint. A project can link specific user stories to each
Solution Train. The user stories that cover multiple Solution Trains can be marked as end-to-end
user stories. For example, in the Hire to Retire process the team can split up this process into
specific epics and user stories for: Setting up different parts of master data, setting up
organizational structure, recruitment, onboarding etc.

Set up planning sessions; Planning sessions are required when using sprints in the project.
Planning sessions allow the team to set up the scope of each sprint. Planning sessions should also
include the check for dependencies with other teams, stakeholders and solution trains.

Set up daily stand-up sessions; A daily stand-up with the team to discuss what each team
member did yesterday, what they are planning for today and to check for impediments.

Set up retrospective sessions; A retroactive session after each sprint will help to optimize the
performance of the team.

Set up refinement sessions; During the refinement sessions the team can check the impact of a
user story within the team and/or with other teams and departments and set up end-to-end testing.

Set up demo sessions; Having the developers demo new functionality to the end users is a good
way to keep the business involved in the SAP project.

Assign the role of Product Owner; The role of Product Owner is very useful in an SAP project.
The Product Owner is the linking pin between developers and business.

Assign the role of Scrum Master; The Scrum Master of a team sets up the planning sessions,
retrospectives and daily stand-up sessions and helps team members solve impediments.

Definition of Done, Definition of Ready; To ensure the definition and verification of quality goals
it is critical to define when a specific work item is completed. For two very important states –
“ready” and “done” the Definition of Ready (DoR) and the Definition of Done (DoD) have to be
defined and agreed upon between the relevant stakeholders.

Public. Copyright © 2023 Sogeti. All rights reserved 35

 TMAP: Quality Engineering for SAP – syllabus

SAP projects

Starting an SAP project

One of the most important things that an organization should do when embarking on an SAP IT
project is to carefully assess its needs and goals. This includes identifying which modules and
functionalities of the SAP software are relevant to the organization, as well as how the software can
be configured and customized to meet its unique requirements. It also means understanding the
potential impact that implementing an SAP system can have on the organization’s operations and
identifying any potential risks or challenges.

Once an organization has a clear understanding of its needs and goals, it can begin to plan and
execute the implementation of the SAP software. This includes identifying the resources that will be
required, such as hardware, software, and personnel, as well as developing a detailed project plan
that outlines the various tasks and milestones that need to be completed. It also means working
closely with the SAP implementation team and other stakeholders, such as IT staff and business
users, to ensure that the implementation goes smoothly and that any problems are quickly resolved.

The focus on quality for SAP projects is different from non-SAP projects. SAP solutions can consist of
standard SAP best practices (available per module) which are commonly used by multiple companies
or custom solutions (also known as Z-transactions) which are specific custom-made functionalities
and code for a single company. The main risk areas for testing SAP solutions are the custom
solutions, interfaces, test data and authorizations (so less on the standard SAP best practices).
These main risk areas require most attention from quality measures and testing activities.
However, the SAP best practices are important to validate the end-to-end processes.

Types of SAP projects

There are several different types of SAP implementations. The choice of the type of implementation
will depend on the organization’s specific needs, resources and goals. Each implementation
methodology requires a different SAP Test Strategy.
Examples of most common SAP implementation project types (that may even be combined) are:
Greenfield Implementation
Greenfield implementation is a type of SAP implementation where the organization is implementing
the software for the first time or starting from scratch in a new environment.
Brownfield Implementation
Brownfield implementation is a type of SAP implementation that takes place in an existing IT
environment where there is already an established system (or multiple systems) in place. The goal
of a brownfield implementation is to integrate the changes to the SAP system with the existing
systems and processes, rather than replacing them entirely.
Bluefield Implementation
Bluefield implementation is a more gradual type of SAP implementation (compared to Greenfield or
Brownfield). Instead of upgrading or replacing a company’s processes, systems and data in one
large approach, a Bluefield implementation means e.g., that only a few teams make the transition
per go-live and that the others will do so at a later point in time. It ensures that the everyday
business activities are not fully disrupted and that the implementation is done step-by-step.
Big Bang Implementation
A big bang implementation is an approach where all the modules and functionalities of the SAP
software are implemented at once, in a single go-live event. This approach is usually used when the

Public. Copyright © 2023 Sogeti. All rights reserved 36

 TMAP: Quality Engineering for SAP – syllabus

organization has a high degree of urgency and wants to see results as soon as possible, however it
can be risky and challenging. Especially for organizations planning to do a global big-bang rollout
covering multiple time zones, a big-bang implementation is a complex and risky operation.
Phased Implementation
A phased implementation is an approach where the SAP software is implemented in stages, starting
with the most critical modules and functionalities, and then adding additional modules and
functionalities over time (minimum viable product (MVP)). This approach reduces the risk of the
implementation and allows the organization to see benefits as they are delivered.
Hybrid Implementation
A hybrid implementation is a combination of different implementation approaches, such as big bang
and phased implementation, where the organization takes advantage of the benefits of both.
Rollout Implementation
A rollout implementation is an approach used when an organization wants to implement the SAP
software in multiple locations, or when an organization is implementing the software in a new
subsidiary. In a rollout implementation a template solution is used for generic processes in multiple
locations. Country or location specific processes are covered in localized templates. Both require
specific attention from a testing perspective.
Upgrade Implementation
An upgrade implementation is a type of implementation where an organization already has SAP
software in place and wants to upgrade to a newer version of the software.
Cloud-based Implementation
A Cloud-based implementation is a type of implementation where the organization chooses to run its
SAP software on a cloud-based infrastructure, rather than on-premises.

SAP Activate
The SAP Activate methodology is a modular and agile framework which helps project teams to
accomplish their tasks to deliver an SAP system to support the business process in bringing business
value. SAP Activate consists of 6 phases:
• Discover
o Familiarize with SAP (S/4HANA) before starting a project to implement SAP (S/4HANA).
• Prepare
o Initial project planning, where the project plan for S/4HANA implementation is defined
which includes team assignments, defining project goals, scope, budget, roles and
responsibilities and project timelines and trainings.
• Explore
o Fit – Gap analysis is done which helps to identify the gaps with standard S/4HANA
o Parallel activities include master data preparation, SAP test strategy & planning and
training set up.
• Realize
o Build, test and validate the business scenarios and processes identified in the previous
phases along with end-users.
o End-users’ training.
o Multiple varieties of testing such as Unit Testing, Integration Testing and User Acceptance
Testing is performed by different stakeholders to ensure the SAP system is configured
according to the customer requirements and meets the pursued business value.
o Data migration testing to ensure migrated data is in the correct format, ready to use and
ready to import to the new SAP system.

Public. Copyright © 2023 Sogeti. All rights reserved 37

 TMAP: Quality Engineering for SAP – syllabus

• Deploy:
o Setup of production system and cutover activities involve uploading master and
transaction data, validating roles and authorizations of end users.
o Perform regression testing to check earlier deployed objects are not impacted.
• Run:
o Business is live with new the SAP solution. After the first period of hyper-care (where any
issues, errors or incorrect entries occurred are corrected) day-to-day operation and
maintenance is starting.
SAP Activate helps to shift from a Traditional ERP approach (Design to blueprint – Waterfall) towards
a transformative (Fit-to-standard – Agile) implementation approach.

Traditional ERP (Design to blueprint) Transformative (Fit-to-standard)

Consultative approach Business owns the solution
Waterfall project methodology Agile, Modular, Scalable
Customized solution Lead with ‘standard’, best practices
Development, not configuration Rapid, repeatable delivery steps
Historically been time consuming and costly Accelerators: tools, templates, and content

SAP Activate supports different transition scenarios for organizations adopting SAP S/4HANA and
provides dedicated solution specific Methodology, Content and Tools.
The SAP Activate methodology is part of the SAP Activate framework. This framework consists of
three important pillars to help project managers use the SAP solution to achieve business goals. The
three pillars are SAP Best Practices, Guided Configuration, and the SAP Activate Methodology.

SAP Best Practices

SAP has developed the knowledge and experience to deliver ready-to-run business processes which
are optimized to run on SAP S/4HANA. This is the first pillar of the SAP Activate framework.
Organizations can access the SAP Best Practices Explorer for all the SAP standard business process
flows, roles, responsibilities, test scripts, etc. which can be integrated alongside the organization’s
own unique processes.

Guided Configurations
Guided configurations make it easier for organizations to configure their SAP systems. To globalize
and standardize best practices across industries, SAP is continually developing standard
configurations that can be used to run business processes.

SAP Activate Methodology

Lastly, the SAP Activate Methodology is a project implementation methodology used to deliver SAP
implementation solutions. Using solution-specific roadmaps, the methodology is then designed to
continuously improve project quality and success of SAP projects.

Public. Copyright © 2023 Sogeti. All rights reserved 38

 TMAP: Quality Engineering for SAP – syllabus

Testing Role Based Permissions for SAP

Testing the Role Based Permissions (RBP) in SAP projects is very important, time consuming and
often underestimated. Organizations have complex requirements for user authorizations, the setup
of RBP is mainly customized for organizations. High customization in general leads to high risks,
which requires high testing effort. The impact when the user authorization is not properly set up is
very high. We need role-based permissions to have proper business controls in place and to restrict
access to sensitive information. A secondary reason for RBP is the need for strict privacy rules (e.g.
compliance with General Data Protection Regulation -GDPR) that need to be followed. Authorizations
are subject to audit activities to verify if the system is correctly configured, and segregation of
duties are assured.

SAP projects should start RBP setup and testing during the early stages of the project. Starting late
might result in missing deadlines and/or authorization issues in the live environment. Testing Role
Based Permissions (RBP) can be challenging in SAP projects. Below you find a description of the
challenging complexity, the need for starting early with planning and the specific considerations
related to testing the RBP.

Complexity: Setting up RBP is a complex and important activity in SAP applications; in SAP projects
it may take a long time to properly set up the RBP. There are a lot of detailed business rules
involved with setting up RBP, that can easily be overlooked when setting up general business
requirements.

Every field, object, transaction and FIORI tile in the SAP application must have the correct CRUD
(Create, Read, Update, Delete) rules set up for each business role represented in the system.
Depending on the number of roles and fields in the system many discussions with the business
owners need to take place to get clarity. The complexity of setting up RBP for SAP applications is
often underestimated by members of SAP projects. Setting up RBP is often a combination of specific
roles and authorization for specific groups of people in specific areas of expertise. For example, a
warehouse clerk should not be able to execute financial transactions, and a Financial Manager
should not be able to execute Hiring employee processes. There will be roles which have overlapping
responsibilities and duties, in this case roles can be combined and assigned to groups or individuals
(in SAP also called composite roles).

Planning: The specifics of setting up the RBP for the SAP applications are not always clear at the
start of the SAP project. As a result of this, projects have the tendency to start late or move the
setup of the RBP towards the end of the project where it often becomes a bottleneck for the project
and ends up on the critical path. Becoming a bottleneck is due to the complexity and the effort
needed to fix problems if the testing of RBP results in many anomalies. Therefore, it is
recommended to start with the configuration of RBP and RBP testing as early as possible. As a hard
entry-criteria, user roles should be in place for the start of the User Acceptance Test (UAT)
execution.

Testing: The testing of RBP in an SAP project can be very complex and time-consuming depending
on how the RBP is set up for the organization. Some companies require more than a hundred roles
and composite roles! Testing all these roles and their access can be very time consuming and can
lead to many anomalies.

Test Preparation: While planning and creating new User Stories, it is worth to check, whether User
Permissions Matrix is updated or if there is a merit to add Role-Tests to that particular Story. By
reviewing User Stories upfront, missing authorizations or roles can be reported. User Roles should
be part of User Story creation and part of the Definition of Ready and Definition of Done. Test
Automation is also an important tool to minimize the risk and save time, since the process of testing
the permissions can be a long-lasting process, and it is error-prone when done manually and
executed multiple times.

Public. Copyright © 2023 Sogeti. All rights reserved 39

 TMAP: Quality Engineering for SAP – syllabus

During the testing of the RBP for an SAP application, it is very important to test all the roles and the
authorizations. The setup of the roles for RBP in SAP is custom work for each project and can result
in conflicts in role authorizations. When testing the RBP the focus should be on the authorizations for
all the roles, are the employees with these roles able to do what they are supposed to do, is there
no conflict in segregations of duty. The SAP authorization consultant is the responsible and main
stakeholder to collect, configure, and set-up the user-roles and system-authorizations. Based on all
information the SAP authorization consultant gathers from all business parts, they create the
authorization matrix for the SAP-project. This matrix is the input to create test cases for the
different (composite) roles and to execute RBP testing.

Note: In small organizations the segregation of duty may be challenging because of the limited
number of people involved.

Public. Copyright © 2023 Sogeti. All rights reserved 40

 TMAP: Quality Engineering for SAP – syllabus

6. SAP quality management

This chapter describes the content related to quality management for SAP.
These additional subjects are based on information that is available on the TMAP body of knowledge
website (www.TMAP.net).
Note: for the exam the descriptions in this chapter supersede any texts on the website, even in case
the website would contain other (more up to date) descriptions. This syllabus is regularly updated to
include the latest insights.

Stakeholder management in SAP projects

Stakeholders are defined as “anyone with viable interest in the business value delivered by the
team, at all levels in the organization and even outside the organization”.
Stakeholder management is about how to involve, enthuse and engage the stakeholders that
matter.

How to identify and involve your stakeholders

When you are involved in organizing IT delivery, for your team, a group of teams, or an organization
as a whole, start with answering the following questions:
• Who are the stakeholders?
• How can these stakeholders be involved?
• What is at stake for each stakeholder?
• What contribution can each stakeholder bring?
• What information does each stakeholder need?

Specific SAP stakeholders

For SAP projects there are specific stakeholders to consider. Depending on how the SAP project is
organized (Agile, V-Model or hybrid), the roles below can be part of an (SAP) Operations team, Agile
team or centralized team. For example:
• SAP Basis Consultant
Provides technical support and performs system administrations tasks.
• SAP Authorization Consultant
Responsible for ensuring the internal and external audit requirements are met. Develop and
maintain standards and procedures for the SAP Security (Fiori, Application and S/4HANA) and
user access controls for all SAP instances.
• (SAP) Business Process Owner (BPO)
Active decision maker and owner of specific local or global business processes. Can determine
change impacts, educate business teams and initiate new business enablement. The process
owned by the BPO can overarch the SAP solution, it can include complete end-to-end
processes (including legacy/ 3rd party systems).
• SAP Key User
An experienced representative of a number of business processes, who knows the processes
in a specific department or for the whole organization in detail and is involved in taking
decisions. They have a leading operational role.
• SAP Master Data Management (MDM) Consultant
Is responsible for the creation and maintenance of Master Data that are fundamental to
business processes that influence the customer experience. Relevant systems and processes

Public. Copyright © 2023 Sogeti. All rights reserved 41

 TMAP: Quality Engineering for SAP – syllabus

include, but are not limited to, the SAP system (like Business Partners, Material Master Data
and Financial Master Data).
• SAP Functional Solution Expert
Is involved in the design, configuration and implementation of functional and module enabled
business solutions (LoB) and functions and plays a critical role in connecting business and IT.
• SAP Technical Solution Expert
Is involved in the design and implementation of technical module enabled business solutions.
They determine clients’ business needs, create customized SAP solutions, and integrate SAP
applications with existing IT infrastructure. They act as advisors for SAP software deployment
and integration. They oversee programming and software development and evaluate existing
IT infrastructure and recommend improvements.
• SAP Integration Specialist
Is responsible for the design, development, and execution of innovative integration solutions
between internal and external information of SAP and Non-SAP systems that support the IT
strategy and overall business objectives.
• SAP Enterprise Architect
Evaluates all business requirements and creates solutions that provide an integrated
approach for SAP processes. This includes deploying SAP solutions and stabilizing core and
non-core SAP systems.
• SAP Test Manager
Is responsible for the planning, management and execution of the testing process, on time
and on budget and at the right quality, for multiple test varieties. The SAP Test Manager
reports about progress of the testing process and the quality of the test object.

Involved stakeholders in an ARCI-matrix

It is important to identify in what role stakeholders are involved in an IT delivery process. This
identification can be made concrete by listing all stakeholders in an ARCI matrix and assigning them
an involvement type.
In the ARCI matrix we distinguish 4 different types of involvement, the name ARCI is an acronym
and based on the first letters of each type of involvement. The involvement-types are:
• Accountable people are also known as the principal stakeholders. They make the final
decisions for example about budget and go/no-go. They must sign off or approve when the
task, objective or decision is complete. This person must make sure that responsibilities are
assigned in the matrix for all related activities. There is only one person accountable per
activity. A person can be both Accountable and Responsible at the same time.
• Responsible people are important because they have a role in making sure that work gets
done, these people are the “doers” of the work. In pure high-performance teams such as in
Scrum or DevOps the team as a whole is responsible and the team members execute the
tasks. In sequential or hybrid IT delivery models there may be just one person responsible or
several people can be jointly responsible and do the work for a task together.
• Consulted people have valuable information or opinions that must be heard prior to making
decisions or who need to give input before the work can be done and signed-off on. This may
be high-level information or detailed information, so people may need to be consulted in very
different stages of the IT delivery process. These people are “in the loop” and active
participants.
• Informed people are the kind of people that do not actively contribute to the IT delivery
process but need to know what’s happening, for example to keep activities aligned across
teams or across organizations. They often are the informal influencers, people that do not
have formal power but do have influence on other people involved.

Public. Copyright © 2023 Sogeti. All rights reserved 42

 TMAP: Quality Engineering for SAP – syllabus

Filling in the ARCI matrix is the result of a proper investigation of the stakeholders, which often
involves a discussion with these stakeholders. Also keep in mind that the stakeholders are not a
static group, so the list of stakeholders in the ARCI matrix and the types of involvement regularly
need to be reviewed and, whenever necessary, adjusted.

SAP Organizational change management

Organizational Change Management (OCM) is a discipline that supports organizations and their
employees in smoothly and successfully introducing an intended change into their ways of working.
Implementing a change within an organization is often complex and has an impact on people’s
everyday work. Therefore, consciously thinking about how to introduce the change and guiding
organizations and their employees towards it is very important.

Why is Organizational Change Management important?

Within IT, ‘Organizational Change Management (OCM)’, or ‘Change Management’ for short, refers to
the different activities that contribute to a successful implementation of a change within an
organization from a people’s perspective. This ‘change’ is generally the introduction of a new
(technical) solution, initiative and/or product, which alters both how an organization might function
as a whole and how individual employees perform their everyday work. In other words, the
organization decides to kick-off a transformation journey towards certain changes in their operations
which will affect its employees. And even though the aim of a change is to achieve organizational
improvements (for example more efficiency, a more up-to-date IT-landscape or opening new
business opportunities), the route towards this change and a full acceptance of it by the employees,
is often complex. The desired change will most likely have a large impact on different areas within
the organization. Think, for example, of employees having to learn about new systems, tools,
structures, roles, and responsibilities and often having to change their mindset or work approach as
well. The support of an OCM team is important for all organizations, but especially when
implementing a (new) SAP-system. This is because:
• A change in or towards SAP-systems often involves many different groups of employees
(teams with different work activities and individuals with different roles/authorizations)
• A change towards an SAP-product often has a long trajectory with many voices. It is
therefore essential to consciously involve end-users early on. If they are forgotten their
confidence and/or support may be lacking, and the implementation may be unsuccessful.

How to create an ambassadors’ network?

For each organizational change and large business transformation, support from the key
stakeholders is essential to accept or reject the change. Getting SAP stakeholders’ commitment and
successfully managing resistance to change, are prerequisites for effective change management.
Acceptance of change (commitment) and rejection of change (resistance) are typically treated as
separate, unrelated phenomena. However, commitment and resistance are closely linked in the
sense that they represent a polarity— two sides of the same coin.
Building on this notion, sequential phases of acceptance of and resistance to change are:
Knowing, Feeling, Doing and Promoting.
To engage stakeholders in the change process and deal with these different phases appropriately, it
is important to involve them as early as possible. A useful approach for this is the creation of an
'ambassadors' network'. Key stakeholders within the organization undergoing the change (for
example, key business users) participate in the change-process from the starting and while doing
so, experience the new solution and its positive benefits quickly. Ultimately, they will become

Public. Copyright © 2023 Sogeti. All rights reserved 43

 TMAP: Quality Engineering for SAP – syllabus

'ambassadors' for the new solution and/or way-of-working and hopefully transfer their positive
attitude towards the change to others who will adopt it later.
It is important to explain the “why” of the change and support them along the whole business
transformation journey.
The table below shows how to work with stakeholders in a way that turns them into true ambassadors
for the organizational change.
Commitment Resistance
(result if change is not well managed)
Knowing Stakeholders are contacted and Stakeholders are unaware and
awareness about the change is created confusion will rise when confronted
with the change

Feeling Stakeholders will understand the why Stakeholders are not involved and feel
of the change and become curious, the a negative perception for the upcoming
necessity is sensed and the desire for change. They show inactivity and are
this change is created against the change
Doing Due to stakeholders’ involvement, they Because stakeholders are not involved,
experiment with the new solution, and they reject the change/new solution
while doing this, they slowly master and might even terminate their labor
the new solution contract or involvement in the
department

Promoting Eventually, the new solution becomes This results in stakeholders’ feeling of
the stakeholders’ new normal which isolation
will result in them becoming the
ambassadors of the change or
transformation

Elements of a successful Organizational Change implementation

1. People centric view
Change Management teams work towards a successful implementation by creating awareness within
the organization of the upcoming change and make sure that end-users and their demands are
involved with the change process at an early stage. Also, by working with this employee-centric
approach, it is possible to create personas, fictional characters which represent a certain user type
and why/how they use a certain product or process.
2. Shared vision on the change
There are several reasons why an organization decides to invest in, for example, new tooling or
restructured ways of working. Organizations have certain “Drivers of Change” which can run from
monetary benefits to technological advancements to cultural shifts or customer demands. Clarifying
and propagating why a change is needed from an executive level towards the organization will
increase the chances of having employees understand the change and eventually accepting it.
3. Clear communication and training plan
In general, the communication surrounding large organizational changes is driven and managed by a
specialist from the OCM-team (so not by Testers, although they are in close contact with the Change
Management Team). The communication towards all possible stakeholders and trainings they are
eventually provided with, need to be tailored, well-timed and right the first time. A change is more
likely to be accepted and well-used when specific and useful information is given to the different
roles that are involved. Often, a smaller group of end-users is introduced to the change at an earlier

Public. Copyright © 2023 Sogeti. All rights reserved 44

 TMAP: Quality Engineering for SAP – syllabus

stage which means they will later serve as ambassadors towards the other, larger group of end-
users when the change is implemented organization wide.

SAP Quality Risk Analysis (SQRA)

Risk comes from NOT knowing what you’re doing: identify your SAP quality risks!

In order to identify where the major quality risks are in your SAP project, execute an SAP Quality
Risk Analysis (SQRA).
The general approach for the SQRA is to conduct a workshop with all involved stakeholders from the
business streams (or SAP Solution Trains/ Line of Businesses (LoB’s)) like Finance, Supply Chain,
Human Resources (HR), Business Warehouse (BW) and even for the Non-SAP systems to determine
the processes and areas with the highest risk. Participants for this workshop are from both the
Business side and IT side.
From the Business side, the following stakeholders should be invited to participate: the Key User,
Functional SAP Consultant, Functional Business Analyst, Product Owner. Stakeholders from the IT
side are: Technical Leads, Technical SAP Consultants, Integration Consultants, System Integrator.
During the workshop, how to rate each process is explained. IMPORTANT: to do a good SQRA
make sure that the detailed scope is clear (preferably on process level), defined and signed off. In
case this is not 100% clear, the SQRA still will identify the risk areas, however it will not be on the
lowest desired detail level. In such case, when the scope becomes more detailed, additional SQRA
workshops should be organized to update the risks.
During the Quality Risks Analysis, the scope of the change or project (regardless of an
implementation, a rollout or an upgrade) is important. Global and local requirements, legal
requirements, language requirements etc., should be included in the Quality Risk analysis.
A quality risk is the chance that the process fails in relation to the expected impact if this failure
occurs. The SQRA is a weighted risk approach where risk input from both Business and IT are
merged into a risk classification:
• The Business input consists of the “Frequency of Use” and the “Business Impact” (Business:
end Key User/ Functional SAP Consultant/ Functional Business Analyst/ Product Owner)
• The IT input consists of the “Process Complexity” and the “Technical impact” (IT: Technical
Leads, Technical SAP Consultants, Integration Consultants, System Integrator (SAP domain
specialist))

To determine the risk, each process in scope is assessed and rated using specific rating definitions.
The rates in the following tables are indicative and can be modified for each SAP Project.

Public. Copyright © 2023 Sogeti. All rights reserved 45

 TMAP: Quality Engineering for SAP – syllabus

Determined by Business Determined by IT

Business Input IT Input
Criteria for Frequency of Use (FU) Rating Criteria for Process Complexity (PC) Rating

Very simple process, main flow + max 2

Used incidentally/ on a monthly basis or less 1 1
alternate flows visible to the user

Used on Weekly basis or monthly basis and over Simple process, max 6 alternate flows, max 10
2 2
10% of all users involved data tables involved

Medium complex algorithm, max 6 alternate

Normal use is on a daily basis 3 3
flows, max 10 data tables involved

Used continually (during office hours or normal Complex algorithms: Multiple decisions or many
4 4
productive hours) dependencies or complex computations

Heavy duty: continual usage by a significant Very complex (combination of complexity

5 5
number of users factors above)

Criteria for Business Impact (BI) Rating Criteria for Technical Impact (TI) Rating

Limited impact (may be caught up or corrected

1 Standard SAP, simple parameterizations only 1
without impacting related business processes)

Errors will induce significant hours to be spent

Extensive parameterizations or relevant
on internal corrections or rework. Primary 2 2
upstream/downstream processing
business process not affected

Errors are likely to affect primary business

processes (e.g. standstill or under performance)
Simple RICEFW* or data setup that has
but impact will be local and have no external
3 significant impact on processing (e.g. basic 3
visibility or are likely to have internal financial
reference model setup)
impact, but financial impact limited to single
transactions

Errors may lead to significant financial losses

Normal RICEFW* or processing significant data
(normally on local scale) or may have external 4 4
setup
visibility

Errors may have structural negative impact on Complex RICEFW* or high impact (master) data
5 5
profitability or organization image setup

*A change request in SAP is called RICEFW

Combined/ weighted risk
The values for each risk component rate from 1 to 5 and have been predefined
using the definitions and guidelines above. The definitions are adaptive and
best practices, it is always possible to adjust and finetune according to the
project specifics and or client needs. The risk classification is the combined and
weighted outcome of the “Business input” and the “IT input” risk score =
(FU+BI)*(PC+TI). With a minimum score of 1 and a maximum score of 100 per
process/ transaction/ test case. (score 0 is No Risk which implies No Test, and
also implies no need for development & implementation)
The values are auto calculated in the template (download from www.TMAP.net)
based on the weighted rates. These risk ranges are indicative and adaptive.
Based on the totals per risk class (the total amount of processes, SAP
transactions, E2E scenarios) the risk boundaries can be adjusted to come to a
balanced risk analysis.

NOTE: Every SAP project is different and will lead to their own balanced overview. Not all objects
can be classified as critical, not all can be classified as low. And there will be objects with no change,
so no risk, no test. There must be a well-balanced average. Therefore the given risk class
boundaries can be adjusted to meet or come close to these references.

Public. Copyright © 2023 Sogeti. All rights reserved 46

 TMAP: Quality Engineering for SAP – syllabus

Example sheet
The results can be captured in an Excel sheet calculating the risk classes.

SAP Quality Risk Analysis - Example Business IT Risk

Com-
Frequency Business Technical Risk
Process plexity Score
of use Impact Impact Class
group Business Process
1 Organizational Structure and Master Data
1.1 Organizational Structure and Master Data
1.1.1 Organizational Structure 2 3 4 4 40 B
1.1.2 Warehouse Structure 1 1 1 1 4 D
1.1.3 Stock types 1 1 1 1 4 D
1.1.4 Product Master 5 2 2 2 28 C
1.1.5 Allergens 3 1 3 3 24 C
1.1.6 Batch Management 3 1 3 3 24 C
1.1.7 HU Numbering 3 1 1 1 8 D
1.1.8 Pallet Labelling 4 5 4 5 81 A
1.1.9 Resource management 3 1 1 1 8 D
1.1.10 Packaging Specification 3 1 1 1 8 D
1.1.11 Hazardous Substance Master 3 1 1 1 8 D
1.1.12 Quality Inspection Rule 3 1 1 1 8 D

The output of an SQRA is input for an SAP Test Strategy (see LO14) and SAP Test Plan (see LO15).
For example: for all objects identified as critical, we have to define one or more test cases to
thoroughly test this object (positive flow, negative flow, happy flow etc.). To create a risk class, you
estimate a value for each of the four risk-components, the result is used to determine your test
strategy. This way you estimate, roughly, the total effort for designing and executing test cases.
(since test cases for critical risk will take more time to design and execute then low-risk test cases.

Test Life Cycle

Based on the location of the test object/ process in the risk matrix (Risk Class), all test objects and
processes are prioritized. The result is ordering of all processes, the most important / highest risk
ones first. In addition to prioritization, a differentiated test approach for the processes can be
defined based on their Risk Class.

This can be used throughout the whole

development life cycle:
• Delivering test objects
• When specifying tests
• When executing tests
• When fixing anomalies

Confidence
Based on the relative level of risk (Risk Class), test design techniques can be selected that will give
the proper level of confidence (see LO07 VOICE MODEL). Keep in mind that within SAP the focus is
on business and E2E processes, meaning that process-oriented test design techniques will bring the
most value (see LO26 Path Testing). Some other test design techniques are still applicable but
should be used earlier in the development life cycle (e.g., during Unit or System Test)

Public. Copyright © 2023 Sogeti. All rights reserved 47

 TMAP: Quality Engineering for SAP – syllabus

Example: Use SQRA in test strategy and test plan

Below an example how the outcome of an SQRA can be translated, converted and used for a test
strategy, test plan and an automation approach.

The outcome of the SQRA will give insights in the Critical to Low-risk areas/ processes. Critical
processes should be tested as soon as possible, at least focus on the happy flow in an early testing
stage, for example SIT. In many big SAP programs, multiple SIT cycles are planned, divide the risk
classes over the several SIT cycles (see picture) and add negative flows for Critical risk classes as
well. When the happy flows are successfully tested, they can be nominated for (manual) Regression
Test Suite and for Automated (Regression) Testing. Per cycle, expand the Regression Test and
Automation Suite.
During UAT, the focus shift to E2E scenarios and processes – Vertical and Horizontal (see LO21) and
all risk classes are involved in these processes as the process steps can be linked to each other as a
chain.
Control mechanisms (quality gates, indicators and metrics) must be in place after each cycle to
reflect insight in status and quality and be input for Go/No Go decisions.

Public. Copyright © 2023 Sogeti. All rights reserved 48

 TMAP: Quality Engineering for SAP – syllabus

SAP Test Strategy

The SAP Test Strategy and SAP Test Plan may be described in a combined document or in separate
documents. There is a strong relationship between the SAP Test Strategy and SAP Test Plan, both
cover specific elements for testing SAP. Both topics are part of the Generic SAP Test Approach. SAP
PRACTICES UP (see chapter 6.5.1) is a great starting point to define the SAP Test Strategy.
Keep in mind, the SAP Test Strategy is part of the SAP Project and should not act independently. It
must be within SAP project boundaries and methodologies. For different types of SAP Projects
(implementation, a rollout or an upgrade) different elements can be applicable for the SAP Test
Strategy.

The SAP Test Strategy is derived from:

- SAP PRACTICES UP
- Test basis (like User Stories, Process Flows, Functional Docs)
- SAP Quality Risk Analysis (LO13)

The SAP Test Strategy is used for:

- Test Plan (LO15)
- Test Design (LO17)
- Test Execution (LO24)
- All kinds of quality measures, quality gates and metrics during various Test Varieties
The SAP Test Strategy is the heart of the SAP testing. The SAP Test Strategy is a linking pin and
input for many topics to be planned, prepared, designed and executed. The SAP Test Strategy itself
is an important foundation for the test design and test schedule.
More details about the Test Strategy can be found in sections 26.5 and 26.6 of the book.

PRACTICES UP

PRACTICES UP is an acronym for all SAP focus areas and provides insight into what needs to be
addressed in the SAP Test Strategy. What focus areas have been impacted by a change? Together
with SAP Quality Risk Analysis (see learning objective LO13) and the available Test Basis,
PRACTICES UP is a helpful guideline for defining an SAP Test Strategy.
The focus areas of PRACTICES UP are described below. Also see www.TMAP.net for more info.

Public. Copyright © 2023 Sogeti. All rights reserved 49

 TMAP: Quality Engineering for SAP – syllabus

Processes
Business processes are leading!
Verifying and validating the output of SAP business processes is the main focus for SAP Testing.
Business Processes are embedded across SAP and non-SAP. SAP and other systems support critical
business processes.

Reports
Everything that is being sent out the organizations must be 100% OK!
All outbound communication needs to be accurate and trustworthy. Reporting requires attention
during SAP testing, especially content and readable layout.

Authorizations
Authorizations have an important role in SAP process handling! (LO20)
SAP is used by large companies with lots of different users: Purchase, Production, HR, Sales,
Accounting, etc. All these users have different business roles and need different permissions in the
application. Some sensitive data, like HR or Financial data, needs to be shielded from standard
users. Some actions, like approving certain amounts of sales orders is only available for certain
people. Authorizations have an important role in SAP process handling and are important to test
thoroughly.

Configuration
Understand the intended behavior that is achieved through customizing!
SAP is an “out of the box” solution, however, to make it fit and operational for the organization,
configuration of business processes, organizational structure, setting up master data and all kinds of
organization specific parameters have to be set.

Transports
A mistake in transport can cause serious issues!
To make SAP functionalities available for the users, all changes and modifications on the system
must be pushed and deployed through the system landscape. Transports ensures, moving changes
made in the Development system to other systems in the SAP landscape, such as Testing,
Acceptance and Production environment (DTAP). Within SAP these are called Transports. Challenges
of transports are:
• Changes must be transferred in the proper sequence
• Sometimes an object is forgotten in a transport
• Object dependencies
• Overwriting of code is a possible risk, especially with variables used
• Rollbacks, in case of any issues during the transport, it may be necessary to roll back to the
previous state

Interfaces
Testing interfaces is a multi-discipline activity! (LO21)
SAP will most likely not exist by itself only, integrations to other (Non-)SAP solutions are linked and
integrated with SAP solutions. During the E2E testing, it is important that processes, data and
communication between systems, are aligned and managed. Besides functional testing of the
integration to validate the business process, non-functional tests are important as well like:
connectivity, performance and security of the interfaces.

Public. Copyright © 2023 Sogeti. All rights reserved 50

 TMAP: Quality Engineering for SAP – syllabus

Conversions
Verify (early) if the processes can handle the converted data!
When new processes in SAP are implemented, different types of data can be needed for verification
of these processes:
• Master- or transaction data from SAP or other systems
• Owner of data is not always clear (e.g.: when used by multiple departments)
• Inadequate monitoring of converted data
• How to check conversion is complete
• Do (new) business processes correctly process converted data?
• Data cleansing

Enhancements
Enhancements require extra test attention and effort during testing!
SAP is an “out of the box” solution, (see Configuration), however not all “out of the box”
configuration will fit the specific business and organization needs. Therefore, custom development is
needed (in SAP this is called ABAP) which is “high risk” as it is new, never used before, code.
• New code created specifically for customer process -> e.g.: Z-transactions
• New code which is part of a new or existing process -> e.g.: specific user exits
• New introduced code which is not part of Standard SAP or SAP Best Practices

Screens
SAP Screens can be heavily modified!
SAP screens and user interfaces can be adjusted and modified to the needs of each user or team.
Screens can be adjusted so only relevant objects are visible. Therefore it is important that the user
interface is fully supporting an efficient way of working, and tested as such, to support the business
needs.

User Experience (UX)

SAP User Experience is how a user experiences, and interacts with, an SAP solution. Improving UX is
important for organizations for End User adaptiveness.
End Users can customize how to work with an SAP solution to suit their personal needs and improve
their overall experience and interaction with the solution (Graphical User Interface (GUI) or FIORI
tiles). User Experience is subjective, however the attributes that make up the UX are objective.

Platform
How does the system landscape influence the SAP Testing Strategy?
SAP can run and connect to many solutions and platforms which can make the landscape complex:
• Cloud (Private, Public, Hybrid)
• On-premises
• Multi-cloud/ Cross cloud (SAP, Google, Azure, AWS, …)
• Platform Data Management
• Integration Suite
• SAP and Non-SAP

Public. Copyright © 2023 Sogeti. All rights reserved 51

 TMAP: Quality Engineering for SAP – syllabus

SAP Test Plan

Various important Quality Engineering activities need to be prepared for an SAP test project. These
activities and subjects are part of the SAP Test Plan. The activities and subjects are divided for the
SAP Test Preparation phase and the SAP Test Excution phase (see LO24). Some of these activities
and subjects are also part of the SAP Test Strategy (see LO19) and are relevant input for other
activities and subjects.
How to deal with an SAP Test Plan and an SAP Test Schedule starts with their definition:
• The SAP Test Plan is an overview of activities and items to be in place for managing the
SAP Test Project, including a description of the activities and the schedule (also called
planning).
• The SAP Test Schedule is the detailed breakdown of testing activities in time, for example,
when to design, prepare, execute and report specifics tests, aligned with the schedule of the
overall SAP Project Plan.
(Note: the general definition of a Test Plan is in section 15.4.2 of the book and in the glossary. A
test schedule in general is defined as: A detailed overview of testing activities to be performed and
executed in a specific sequence and time.)
In any SAP IT delivery lifecycle model, a schedule with work items and timelines needs to be created
to manage the execution of test activities. This is an SAP (Master) Test Plan in a sequential IT
delivery model, and it is a backlog and scrum board in a high-performance IT delivery model.
The SAP Test Strategy is the reference of the organizing and performing activities of the test tasks
and serves as an instrument to communicate with the stakeholders on strategic and tactical level.
The SAP Test Strategy balances the allocation of quality measures and the investment of testing, to
make an optimal distribution of effort over test varieties and test approaches and determines test
coverage and test intensity. The SAP Test Plan describes the SAP test project, including the activities
and the schedule. Keep in mind that a test plan is NOT a description of the actual tests (logical and
physical test cases). The SAP Test Plan is the linking pin between the tactical and operational level.
The Test Plan translates the Test Strategy in such a way that everyone in a test project can
understand the activities to be done.

Public. Copyright © 2023 Sogeti. All rights reserved 52

 TMAP: Quality Engineering for SAP – syllabus

Input for the SAP Test Schedule:

Besides the SAP Test Plan, which describes the roadmap to achieve the agreed goals and quality,
the SAP Test Schedule uses the Project Scope and the SAP Quality Risk Analysis (see LO13) as input
for a detailed overview of tasks and activities in the project’s timeline. The output of SAP Quality
Risk Analysis (risk classes) is used to determine test intensity and the sequence of test activities to
be executed. It balances the time used for test case design and test case execution. Higher risk
parts get more effort than lower risks. The schedule should start with the most critical risk areas and
processes first, spread out over the different test varieties (like SIT, FAT, UAT, E2E, RT). See the
glossary on www.TMAP.net for the definitions.

Governance, Indicators & Reporting in the SAP Test Plan

An important part of the SAP Test Plan is to have a test governance structure in place which is in
line with the project needs and stakeholder expectations. Examples are: which meetings will be
scheduled, which deliverables will be shared, what is the frequency of meetings and reports, and
which stakeholders will be involved.
Furthermore, an overview of relevant indicators and metrics should be included in the SAP Test Plan.
These indicators will give insight in progress during test design and test execution stages. More on
indicators and reporting in LO25 SAP Indicators and Test Reporting.
Eventually, all insights in quality gates, indicators and metrics, contributes to establish the
confidence that the business solution, consisting of the whole SAP landscape/ scope, other systems
and business processes, will deliver the expected business value.

Quality gates

What is a quality gate?

A quality gate is a milestone in an IT project that requires predefined criteria to be met before the
project can proceed to a next phase. It is important that the demand and supply party are aligned
on the expected quality levels. These responsibilities should be transparent and clear in advance.
A quality gate can represent the start or end of a testing phase and can be visualized by a checklist.
This checklist is used during and at the end of a testing phase in an SAP project. It requires
predefined criteria to be met before the project can proceed to the next testing phase. This checklist
contains entry and exit criteria. The most important aspect of a quality gate is that all involved
stakeholders agree that a certain testing phase is completed and that the project is ready for the
next testing phase or go-live. Fill out the quality gate checklist with all stakeholders involved and
discuss the status of the quality gate at the end of a testing phase. Besides using quality gates to
start a particular testing phase, quality gates are also used for project phase transitions.

Quality gates in the Demand/ Supply model (hybrid)

In SAP projects quality gates are often used for the handover between solution-teams, the System
integrator, the (business) testers, and internal and external parties, when starting a different testing
phase in the project. This is called a Demand/Supply model (see section 5.5.1).

When the demand party works according to a sequential IT delivery model, a project manager and a
test manager are assigned to the project. The supplying party working with Scrum will have a Scrum
team with a product owner, scrum master, and team members. This setup may lead to tensions
between demand party and supply party, for example when the project manager has a clear end

Public. Copyright © 2023 Sogeti. All rights reserved 53

 TMAP: Quality Engineering for SAP – syllabus

date of the project, but the Scrum team determines what to deliver for every individual sprint. This
can be mitigated by having clear agreements about the handover between demand- and supply
party and (later) between supply – and demand party.
At a general level, you could distinguish the goal of the demand and supply parties as follows:

- The demand party establishes what is required and validates if that has actually been
delivered and whether they have actually achieved the pursued business value.
- The supply party evaluates the requirements and uses these to configure the SAP solution,
working towards the definition of ready. The supply party delivers the IT system and
demonstrates that what is demanded, is actually delivered.

In this situation there are two clear quality gates: one where the demand party hands over their
requirements to the supply party, and one where the supply party delivers the IT system to the
demand party (see LO05 IT delivery models for SAP).

Example quality gate checklist

Some examples to include in a quality gate checklist to start a SAP User Acceptance Test (UAT):
• Are SAP business testers selected and are their schedules blocked for the UAT period?
• Are SAP business roles ready and available?
• Are SAP business roles and SAP logons mapped for the attending SAP business testers?
• Are the required interfaces for the SAP application available?
• Is the set-up of integration partner profiles ready and available?
• Is the test environment set up and available for the SAP business testers?
• Is the test environment filled with correct test data?
• Is availability and correctness of SAP master data validated?
• Is the in/ outbound communication verified for all interfaces?
• Are test cases for UAT available?
• Is there a physical room booked for the UAT?
• Is all the required hardware available?
• Is anomaly management procedure available, clear and set up?
• Are SAP business testers properly trained?
• Are developers available to fix anomalies found during UAT?
• Are all blocking problems from previous testing phases fixed or handed over as known error?
• Are work instructions and release notes available?

A quality gate is monitored during the testing phase and has a deadline that matches the end of one
testing phase. If the quality gate is not completed at the deadline, it is important that the test
manager takes the following actions:
1. Discuss with the involved stakeholders which actions need to be completed to start the next
testing phase or go-live.
2. Set new actions and deadlines together with stakeholders and make sure the actions are
assigned.
3. Make sure that all required resources are available to complete the open actions to meet the
quality gate.
4. Inform all stakeholders about the delay in the next testing phase or end of the project and
discuss and share how to move forward. This can impact the Go/No-go for the go-live of the
project.

Public. Copyright © 2023 Sogeti. All rights reserved 54

 TMAP: Quality Engineering for SAP – syllabus

SAP Test Execution

The execution of tests is one of the most important parts of dynamic testing. Test execution is
described in the book (chapter 33). Various people with the role of tester will execute test cases in
the SAP test environment. A test case consists of preconditions, steps with input and actions, and
expected results.
Before the test execution starts the tester performs some pre-activities, such as test environment
setup, test case design, and test data preparation.
During test execution the tester uses the test scenario to follow the steps of each test case and
determines if the test is passed or failed by comparing the expected result (of all steps) with the actual
result. When the tester observes an anomaly during the test execution, the anomaly will be logged
according to the anomaly management process, see chapter 7.4.
After the test execution has ended the tester investigates and assesses the outcome of the testing
(see chapter 34 of the book). If any anomalies are observed these are reported, so that the anomaly
management process can be followed. And as a closing activity there are “test cleanup” activities such
as making sure the user is logged out of the system and the database is cleaned up when needed.
The test execution may differ for different test varieties, for example because the scope is different,
different people are involved and different tools are used. Based on the nature of the SAP project
some specific test varieties may be applicable, separately or combined. As per the SAP Activate
methodology (refer to learning objective LO12) the following test varieties are often relevant:

• Unit Test
• System Integration Test
• User Acceptance Test
• Regression Test

Unit tests are developer specific and not relevant for the target audience of this training course.

Business users, operations – and maintenance people are mainly involved in User Acceptance
Testing and sometimes in System Integration Testing. They often may be involved in Regression
Testing. During test execution, the testers will assess actual outcome versus expected outcome.
Progress and any observations or anomalies will be logged.

The following sections briefly describes these relevant test varieties.

System Integration Test (SIT)

System Integration Testing is performed to verify proper execution of the entire application including
interfaces to external applications (Refer to learning objective LO21 end-to-end testing). This aims
to ensure that the integrated components are functioning properly according to the requirements
and specifications. Mainly focused on in- and outbound communication to check if connectivity is
established between systems in scope.
It is a test carried out by operations- and maintenance people, and possibly involving future users,
with the aim of demonstrating that (sub)system interface agreements have been met, correctly
interpreted and correctly implemented.

Public. Copyright © 2023 Sogeti. All rights reserved 55

 TMAP: Quality Engineering for SAP – syllabus

User Acceptance Test (UAT)

UAT is a test variety carried out by (or on behalf of) the future user(s) in an optimally simulated
production environment, with the aim of demonstrating that the system supports the operational
process of the users. Activities included for this phase are:
• Prepare a User Acceptance Test plan,
• Prepare and document User Acceptance Test Cases,
• Execute User Acceptance Test Cases,
• Handle anomalies according to the anomaly management process agreed within the
organization,
• Obtain User Acceptance Test Sign Off to formalize the acceptance.

Regression Test (RT)

The implementation of a new system or changes to an existing system may impact existing IT
systems and SAP business processes. Therefore, after each change a regression test should be
executed to confirm that no unforeseen impact exists in the parts that should not have been
changed. Because regression tests usually have to be executed very often the execution is
preferably automated using a test execution tool.
A regression test may be a separate test variety, but often it is combined with a SIT or UAT.

Other Test varieties

It is also recommended to assess the need for other test varieties (such as non-functional testing).
Examples are Performance Testing (Refer to learning objective LO33 and chapter 37 of the book),
Usability Testing (see chapter 39 of the book) and Security Testing (see chapter 40 of the book).

Public. Copyright © 2023 Sogeti. All rights reserved 56

 TMAP: Quality Engineering for SAP – syllabus

7. SAP Infrastructure and tooling

This chapter describes the content related to infrastructure and tooling for SAP.
These additional subjects are based on information that is available on the TMAP body of knowledge
website (www.TMAP.net).
Note: for the exam the descriptions in this chapter supersede any texts on the website, even in case
the website would contain other (more up-to-date) descriptions. This syllabus is regularly updated to
include the latest insights.

SAP Test data (management)

Understanding SAP data

In today’s businesses the speed of change is continuously accelerating. And every change in an SAP
system drives test data needs. A Test Data Management (TDM) strategy and solution, is critical and
enables testers to find and use the relevant test data for SAP systems.

In SAP, data is built up through various modules such as Material Management (MM), Sales and
Distribution (SD), Financial Accounting (FI), and Production Planning (PP). These modules allow the
entry and management of different types of data, such as material master data, customer master
data, vendor master data, and financial data. The data is stored in tables within the SAP database
and can be accessed and modified through transactions within the SAP system. It is also possible to
extract or input data using API’s (Application Programming Interface) to interface with SAP. The
data structure in SAP is organized in an hierarchical manner, ensuring data consistency and integrity
throughout the system.

Configuration data and master data are a prerequisite to start testing in any SAP project. All other
test data can be generated using the master data.

Understanding the use of Master Data in testing SAP E2E processes is critical, regardless of whether
testing is taking place on ERP Central Component (ECC) or S/4HANA, as well as external
applications.

SAP has the following data classes:

• Configuration Data: Defines the system and the limits of all elements, e.g. Organizational
structure, warehouse set-up, and product-specific configuration (preconfigured settings are
adjusted to better fit the needs of the business).
• Master Data: Defines the material-, vendor-, customer-, and financial data and how they
will behave in the system.
• Conditional Master Data: Applies only in specific situations (e.g. for this customer and
material, use this price)
• Transactional data: Depends on conditional data and master data, includes key operational
data.
• Reporting: Depends on transactional activity.

Master data will determine the behavior of SAP (for example condition records).

Public. Copyright © 2023 Sogeti. All rights reserved 57

 TMAP: Quality Engineering for SAP – syllabus

Ideal test data set

Software development and testing will only be successful with carefully prepared test data. Do not
use just some data or just a random test case because in that case you do not know what result to
expect. To test a software application effectively, you’ll need good and representative data. The
ideal test set covers all relevant application parts with the smallest possible test data set. In short,
you need a relatively small test data set that is realistic, valid, and versatile.
Manually generating test data is a time-consuming activity. Without a structured approach it does
not guarantee an appropriate test coverage.
Using a copy of the live production data has several drawbacks:
• Development and testing teams will have access to sensitive information, so data needs to be
scrambled and/or anonymized (to comply with privacy rules such as the General Data
Protection Regulation of the EU, also known as GDPR).
• Creating copies of production data into non-production environments typically requires a lot of
time, leading to a lack of environment availability.
• Non-production environments need to have the same capacity as the target landscape, which
means that infrastructure costs will be higher than necessary.
• Data requirements can be different for different applications and can have different formats.

Synthetic data
Synthetic data is artificial data that is generated from original data and a model that is trained to
reproduce the characteristics and structure of the original data. Selecting and using test data in SAP
can be time-consuming. Even generating synthetic test data instead of copying data from the live
environment, has a number of challenges. Examples are:
• Complex data structures: SAP systems have complex data structures, making it difficult to
locate the specific data required for testing.
• Data duplication: SAP systems often have duplicate data, making it difficult to determine which
data is relevant for testing and which data is not.
• Data privacy: There may be sensitive data in the SAP systems that needs to be masked or
removed before it can be used for testing purposes.
• Data consistency: The data in SAP systems may not be consistent, making it difficult to find
and use accurate data for testing.
• Lack of standardization: There may be a lack of standardization in the way data is stored in the
SAP systems, making it difficult to locate the specific data required for testing.
• Specific data & systems settings especially for any Test Environment to avoid and block any
outbound communication to the real world.

Below we describe a number of possibilities to properly create test data sets for an SAP system.

Sub-setting
Sub-setting is the process of selecting and retrieving a subset of data from a larger dataset, based
on certain criteria. Data sub-setting and extraction can help to achieve the ideal test data set. The
goal of data sub-setting and extraction is to extract the relevant information from a large dataset, so
that it can be analyzed and used to support decision making or other purposes. Data sub-setting
involves selecting a portion of the data that is of interest and excluding the rest. This process is used
to reduce the amount of data that needs to be processed, which can make the testing more efficient
and manageable. The criteria used to select the data can vary, but they often involve specific
attributes, such as date, location, or type of data. Sub-setting can also be sustainable as less data is
stored in the database, so less resources are used.

Public. Copyright © 2023 Sogeti. All rights reserved 58

 TMAP: Quality Engineering for SAP – syllabus

Sensitive data
Handling sensitive data during testing in an SAP system requires a careful approach to ensure that
the data is protected and that the testing process does not compromise security and privacy
regulations. Here are some key considerations for handling sensitive data during testing in SAP:
Data masking
During testing, sensitive data should be masked or replaced with fake values that still preserve the
overall structure and relationships of the data. This can be achieved using data masking techniques,
such as substitution, redaction, or encryption.
Access control
Access to sensitive test data should be restricted to only those who have a legitimate need to access
it. This can be achieved through role-based access control, which assigns permissions based on the
user's role within the organization.
Secure testing environment
The testing environment should be secure and separate from the production environment to prevent
unauthorized access or data breaches.
Compliance
Organizations must comply with relevant laws and regulations regarding the handling of sensitive
data, such as the General Data Protection Regulation (GDPR) in Europe and the Health Insurance
Portability and Accountability Act (HIPAA) in the United States, these apply even during the testing
phase.

It is important to keep in mind that the specific measures required for handling sensitive data during
testing in an SAP system will depend on the nature of the data and the specific regulations and laws
that apply to the organization. A risk assessment should be performed to determine the specific
security measures that are required, and a security plan should be developed to ensure that the
data is protected during the testing process.

The end-to-end process in SAP

It is important to keep in mind that the end-to-end (E2E) process in SAP is a complex and
interdependent process, and any changes or updates to one part of the process can impact other
parts of the process. A thorough understanding of the E2E process is crucial for successful
implementation and use of SAP in an organization.
Testing provides a comprehensive view of the behavior of the business processes that are supported
by the SAP system. Testing with an E2E perspective shows whether all components of the system
work together seamlessly, and if the system meets the business requirements.
Test data plays a crucial role in the testing of the E2E process in SAP, testers typically use a subset
of the production data that represents various business scenarios. The test engineer needs to
charter the E2E process and detail what’s happening with the master data and transactional data.

Public. Copyright © 2023 Sogeti. All rights reserved 59

 TMAP: Quality Engineering for SAP – syllabus

Specific considerations for a CI/CD pipeline in SAP

Modern IT delivery teams strive to reduce the duration time of delivery of a change to a system to
the minimum. For this reason, many tasks are preferably automated using a CI/CD pipeline. A
CI/CD pipeline is a set of automated activities (using tools) that implements the Continuous
Integration & Continuous Delivery (CI/CD) principle for specific capabilities that are required in the
IT delivery process. For instance, when committing a change, a set of quality assurance checks is
done, such as automated code review and the regression test cases are executed.
SAP can provide predefined CI/CD pipelines to automatically build, test and deploy your specific
code changes and to speed up your delivery cycle. CI/CD can be achieved with a mix of tools both
from SAP and others, for instance Azure DevOps.
SAP can provide various ready-made SAP CI/CD pipelines, for example an ABAP environment
pipeline and a General Purpose Pipeline. And SAP provides a shared library with reusable step
implementations to create customized pipelines.

Figure: Basic setup of a CI/CD pipeline (Figure 6.1 of the book Quality for DevOps teams)

Public. Copyright © 2023 Sogeti. All rights reserved 60

 TMAP: Quality Engineering for SAP – syllabus

SAP Test Management tools

Introduction to test management tools

Note for the reader: This section is an extension of the information in chapter 23 of the book.

A test management tool can support the test team in an SAP project in the following ways:
• Setting up the test strategy
• Creating and maintaining release/ project cycle information
• Managing (Agile) planning activities
• Integration with open-source frameworks
• Creating and maintaining the test artifacts (Requirements, test scenarios/ suite, test cases,
anomalies) specific to each release/ cycle
• Establishing traceability and coverage between the test artifacts
• Test execution support – test run execution and status and screenshot capture
• Metric collection/ reports and graphs generation for analysis
• Setting up and maintaining anomaly management
• Set up regression testing and orchestrating the test automation
Some examples of test management tooling that are commonly used for SAP projects are:
• SAP Solution Manager
• SAP Cloud ALM
• Microfocus ALM
• Tricentis qTest
• Microsoft Azure DevOps
• Jira
• Zephyr
• XRAY
• And many more

Effects of test management tools

Some positive effects that a project can achieve by using test management tools are:

• Combining the ability of managing business requirements, test cases and anomaly
management with traceability, coverage and insights in requirements that require additional
attention.
• Reducing the total time of the testing activities of a project. Effective use of a test
management tool can, when efficiently used, decrease the required time to create and
execute all required test cases.
• Being able to assign test cases to different testers and track the progress.
• Test management tools can trigger test execution (tools), which accelerates test execution
and generates the information about quality and related risks. It gives all stakeholders
insights in the quality of the delivered SAP solution.
• Getting better coverage of the test cases and being able to give insights in the coverage of
the test cases.
• Create real-time management reports with the progress of the testing.
• Able to reuse test cases for different test varieties

Public. Copyright © 2023 Sogeti. All rights reserved 61

 TMAP: Quality Engineering for SAP – syllabus

SAP Anomaly management

An anomaly is a difference between the expected behavior and the actual outcome of a test. This is
registered so that the cause can be analyzed and resolved. In SAP projects, often an anomaly is
called a defect, but because this term can be very confusing, we use the term anomaly as specified
by the IEEE 1044 standard. Synonyms commonly used in SAP are Defect, Issue and Bug.
The process of identifying, investigating, and resolving anomalies is known as anomaly
management. An anomaly must be investigated and when the cause of the problem is found, it can
be fixed. If the problem was caused by a fault in the IT system, then a change to the IT system
(and/or the data) is needed. If the anomaly was caused by a fault during testing, then the test must
be changed.

After fixing an anomaly, the test involved is retested to confirm that the fix has solved the anomaly.
At the same time, a regression test is often done to confirm that the fix did not introduce any new
problems.
When the fix of anomalies found during SAP testing is not possible as part of the sprint, anomaly
meetings should be held to discuss possible actions:
• Prioritize the resolution of the anomaly: Assess the business impact and prioritize it
accordingly. If it is a critical problem, consider moving it to the top of the backlog and
addressing it as soon as possible.
• Workaround: Develop a workaround to temporarily resolve the problem until the fix is
implemented. Or consciously decide, with the appropriate stakeholders, to make it a
permanent workaround and not fix the problem.
• Defer the fix: If the impact is low defer the fix to a future sprint.
• Escalate the anomaly: If the impact of the anomaly is significant, escalate the anomaly to the
appropriate level of management for a decision on how to proceed (like a dispute meeting).
• Update stakeholders: Keep relevant stakeholders informed of the status and action taken to
resolve it.
The goal of anomaly meetings is to bring the right people together to assess the impact of the
anomaly, prioritize it, and work towards its resolution. Participants to include in anomaly meetings:
• Project Manager (or Product Owner in Agile teams): To ensure the resolution is aligned with
project timeline and budget.
• Business key user(s): To provide a functional perspective and to prioritize anomalies based
on their business impact.
• Development team representatives: This includes both ABAP developers and functional
developers. ABAP developers provide a possible technical implementation of the solution,
technical feasibility of the solution and effort required to resolve the issue. Functional
developers provide the perspective on functional design and configuration related changes if
needed.
• Testing team representatives: To provide detailed analysis of the anomalies found during
testing and to provide an estimate of retesting efforts related to the fix.
• Scrum Master: May or may not be required, depending on the specific circumstances of the
project.
The purpose of anomaly management is to fix problems but also to provide information to improve
the IT delivery process. It is important in the continuous monitoring of product quality throughout
the whole lifecycle of the product.
Anomaly management in SAP projects is different from other projects in the following ways:
• Systems are often customized according to specific business requirements.
• SAP systems integrate with multiple other systems.
• It may be difficult to isolate the root cause of an anomaly and determine its impact.
• Correct working of an SAP system also heavily depends on quality of (test) data.
Anomaly management should be supported with tools. Usually these are Test Management tools.

Public. Copyright © 2023 Sogeti. All rights reserved 62

 TMAP: Quality Engineering for SAP – syllabus

SAP Test Automation & Tooling

Why test automation?

Note for the reader: This section is an extension of the information in chapter 32 of the book.
Test automation focuses on automating the execution of test scenarios (preferably for the entire
end-to-end business process) to analyze the quality of the application(s). These test scenarios are
coming from realistic business processes, which might also consist of back-end calls (API testing) to
help with speed and efficiency and enable very frequent execution of tests (e.g.: in a CI/CD
pipeline). In the automation process checks/verifications are a vital part of building tests to ensure
that the actions are taken correctly, since automation is in essence telling a machine what to do and
validating what’s happening in the application to ensure that the scripts are executed correctly and
failures/ unexpected results are shown. Examples for SAP would be to verify the message in the
status bar and store the created/changed order for later usage to ensure the action was performed
successfully.
When deciding on implementing test automation, the reason for starting it is key to being
successful. Ensuring speed in the testing process might be a reason. A test automation tool itself
cannot solve issues such as delays within your systems or missing data. Stakeholders can do this by
being aware of the shortcomings in the processes that are related to quality engineering & testing
and selecting tools to mitigate these shortcomings. By doing so, more benefits of test automation
can be achieved. The effects of using test tools is described in figure 23.1 of the book.
Knowing on which layer of the testing pyramid to automate and which tests to select for different
purposes is a vital part of effective test automation, for more information see the description of the
test automation pyramid in section 37.2 of the book. Overall, the main opportunity for SAP Test
Automation would be for regression testing purposes, since this test variety tends to be linear in
nature, which ensures predictability of the outcome of a test. This helps to identify where issues lie
that need to be solved.
Examples of tools for automated test execution are:
• Tricentis Tosca
• SAP S/4HANA Cloud Test Automation Tool (TAT)
• Worksoft certify
• Selenium
• Cucumber
• Robot Framework
• Qualibrate
• And many more

Prerequisites for starting test automation in an SAP environment

Business success factors:

• Clearly specified end-to-end test cases (including expected outcome) are available.
• Common understanding of the impact of processes and cut-off points.
• Awareness of the trail the data will travel, and how this impacts specific processes/triggers.
• Understanding functional changes of new releases for maintaining and implementing these
changes in the automated test cases.
• Business alignment by engaging all stakeholders to share advantages of SAP Test automation
as well as challenges faced.
• General understanding of SAP Test Automation possibilities and limitations.

Public. Copyright © 2023 Sogeti. All rights reserved 63

 TMAP: Quality Engineering for SAP – syllabus

Technical success factors:

• Infrastructure for the tool to be deployed, with access to the applications to be tested, also
considering cloud environments for unattended execution.
• Access rights for the test automation engineer, and also for the test automation tool itself, to
the different systems, for automation purpose with the right authorizations for different roles.
• Configuring SAP for allowing scripting to be possible with the test automation tool.
• Selected tool is the right fit for steering SAP, the test environment is stable (or mitigating
factors are considered) and test data is available /can be created to replicate the scenarios to
be tested.

Dealing with complexity of SAP test automation

SAP brings complexity for test automation compared to other systems due to the large overlaps in
the processes and many different variables such as Master Data & User role set-up. There are quite
some dependencies when testing end-to-end, as an entire E2E-process can consist of many different
systems that can be regionally different. It is important to carefully select test cases for automation
of the end-to-end test, to prevent it from being too large, and to prevent overlap with other tests.

Reusability (Master Data & User Roles)

Within test automation it is useful to work with reusable steps and for SAP processes this is quite
easily done through making blocks for different transaction codes or Fiori tiles that only differ in the
data that has to be processed throughout the application or user that will perform the action.
Reusable blocks also ensure that maintenance can be done in an efficient way, considering it only
needs to be done in one place when parameters change for a sales order or extra steps are added.

Bottlenecks in test automation in an SAP environment

The following challenges and bottlenecks may be experienced when applying test automation.
Discussing these bottlenecks upfront of the SAP Test Automation project will create awareness and
helps solving these issues:
Automation is an isolated island
• This leads to not being aware of new releases and the impact on test automation.
• Not getting the benefits of collaboration and awareness of what test automation can do for
different teams.
• Overlap in what is tested manually and through automated testing.
Bad test cases
• The results of the automated test execution are not useful when the test cases that are
automatically run do not align with the goals of the test variety and the information needed by
the stakeholders.
Test data
• Incomplete, incorrect and changing master data are concerns for effective test automation.
Thinking test automation assures higher speed of the testing process
• Sometimes parts must be executed manually.
Instability of the environment/ technical issues
• System time outs,
• Installation/ configuration errors,
• Network/ hardware errors,
• Application errors.
Complex end-to-end processes
• When multiple SAP and non-SAP (e.g.: 3rd party and legacy) steps are not well defined nor
clear on what the outcome should be, these should be broken down into logical scenarios to
avoid SAP integration dependencies for SAP Test Automation.

Public. Copyright © 2023 Sogeti. All rights reserved 64

 TMAP: Quality Engineering for SAP – syllabus

SAP Performance Testing

Why SAP performance testing?

Applications that have the right performance level will enable users to complete transactions quickly,
which will speed up business operations during peak performance.

Performance testing for SAP will reduce the risk of the business processes to not perform as per the
non-functional requirements. It will provide insights into the time behavior, resource utilization and
capacity of SAP applications and the business processes they support.

Examples of tools for performance testing are:

• Tricentis NeoLoad
• LoadRunner
• JMeter

Types of performance testing

Load Testing: used for exercising the system to perform the various expected loads on a
component level as well as an end-user level. On a component level, performance testing will test
for conforming to basic performance requirements (database transactions per second, API-calls per
second etc.). At the end user level, the performance in a real-life situation with users “hitting” the
system from all possible interfaces in real life is tested (mobile/ web/ workstation etc.).

Stress Testing: this aims at going beyond the regular load expectations/ requirements. This may
vary from looking ahead to an expected increase in load over the months or years to aiming for the
system to break (in order to test failover/ restore processes).

Endurance Testing: this is used to determine whether the system can sustain continuous expected
load. Duration can be for example from 8 hours to 2 weeks for the endurance test. One of the
purposes of an endurance test is to identify memory leaks.

Volume Testing: a volume test is executed with a huge volume of data in an SAP performance test
environment to identify and validate the performance with realistic data volumes.

Common issues in SAP performance testing

Test Data: To execute performance testing, large quantities of test data are required. The data are
used multiple times. Testers need to make sure test data does not expire after one iteration. In SAP,
test scenarios are executed with master data (like Material Master, Business Partner master) and
transaction data (like Purchase Requisition, Purchase Order, Invoice etc.), so creating large numbers
(1000 transactions = 1000 Purchase Requisitions, 1000 Purchase Orders, 1000 Invoices) may be a
very difficult and time-consuming process.

Real-time performance environment: Performance testing should be executed in a production-

like environment. Performance metrics like number of users, number of transactions, response time
are derived based on the production environment. However, performance tests are commonly
executed in non-production environments which often have a lower capacity than the production
environment. This means the results of the performance tests may not be 100% accurate.

Project Stakeholders: Many of the project stakeholders (Business Team, Infrastructure Team,
Basis Team) are not aware of the importance of performance testing.

Public. Copyright © 2023 Sogeti. All rights reserved 65

 TMAP: Quality Engineering for SAP – syllabus

SAP End-to-end testing, vertical and horizontal

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 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

Public. Copyright © 2023 Sogeti. All rights reserved 66

 TMAP: Quality Engineering for SAP – syllabus

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),
o 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 (see LO20).
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

Public. Copyright © 2023 Sogeti. All rights reserved 67

 TMAP: Quality Engineering for SAP – syllabus

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 (see LO30).
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 (see LO23).

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.

Public. Copyright © 2023 Sogeti. All rights reserved 68

This syllabus is maintained by the members of the TMAP Special Interest Group and the Sogeti
Academy. You can contact the Sogeti Academy in the Netherlands at [email protected].
You can contact exam provider iSQI at [email protected].

About Sogeti
Part of the Capgemini Group, Sogeti makes business value
through technology for organizations that need to implement
innovation at speed and want a local partner with global scale.
With a hands-on culture and close proximity to its clients, Sogeti
implements solutions that will help organizations work faster,
better, and smarter. By combining its agility and speed of
implementation through a DevOps approach, Sogeti delivers
innovative solutions in quality engineering, cloud and application
development, all driven by AI, data and automation.

Capgemini is a global leader in partnering with companies to

transform and manage their business by harnessing the power of
technology. The Group is guided every day by its purpose of
unleashing human energy through technology for an inclusive and
sustainable future. It is a responsible and diverse organization of
nearly 350,000 team members in more than 50 countries. With its
strong 55-year heritage and deep industry expertise, Capgemini is
trusted by its clients to address the entire breadth of their
business needs, from strategy and design to operations, fueled by
the fast evolving and innovative world of cloud, data, AI,
connectivity, software, digital engineering, and platforms. The
Group reported in 2022 global revenues of €22 billion.

Visit us at www.sogeti.com

This document contains information that may be privileged or

confidential and is the property of the Sogeti Group.
Copyright © 2023 Sogeti.