Is integration testing same as UAT?

User Acceptance Testing (UAT) and System Integration Testing (SIT) are two great
examples to dive in deeper and review. UAT represents testing whether an
application meets the business need whereas SIT represents the testing of an
application to ensure it meets its engineering specifications.

First things first… What is SAP?

SAP (System Applications and Products) is an integrated or centralized ERP-system (Enterprise
Resource Planning) to make core business processes work efficiently. It consists of several fully
integrated modules, which cover virtually every aspect of business management. It provides
customers the ability to interact with all common corporate databases for a wide range of
functional and technical modules[1], e.g. Customer Relationship Management (CRM), Financial
Management (FI), Human Capital Management (HCM), Product Lifecycle Management (PLM)
and Supply Chain Management (SCM). It also offers business analytics tools to help businesses
streamline their processes and be more competitive.
To put it simply: SAP ERP  is software and hardware to run a company.
SAP is #1 in the ERP market in terms of revenue, and #2 after Microsoft in overall business
applications revenue. As of 2018, SAP has more than 437.000 customers in 180 countries. It can
be deployed both on-premise as in the cloud and is suitable for large, as well as small and
midsize enterprises (SMEs). It has a mobile app for both Android and iOS systems.

Testing SAP systems

(SAP) Testing skills
The testing skills you need for SAP testing are basically the same as for any software application
testing, but the big difference is that all the hard work you put into understanding and
gaining deep functional knowledge of the modules and/or SAP system isn’t obsolete when
you switch projects or companies.
E.g. when you switch from testing a billing system of a Telecom company to another billing
system from a Bank or even a competitor Telecom company, chances of it being the same or
using similar modules, terminology, and even functionalities, is next to zero…
In case of SAP, the functional knowledge you acquire is portable and can be used in any other
SAP testing project. If you are switching from an SAP finance module test project in a Telecom
company to an SAP finance module test project in a Bank, you will instantly recognize the GUI,
transaction codes and vanilla business workflows. Of course, you will need to learn the
customizations made by the client, but this is a huge advantage.

Maintenance
A big part of SAP testing is triggered by maintenance, called maintenance testing. Once the
SAP system is configured, customized, deployed and operational (live) – any changes made to
the SAP system is ‘maintenance’. E.g.: new feature additions, bug fixes, kernel updates, support
pack & stack updates, or OSS note implementation.

Test phases
There are different lifecycle methodologies for SAP implementation. E.g. ASAP
Implementation (initial implementation and transfer from legacy systems), Maintenance
lifecycle, Upgrade lifecycle, and Custom Development lifecycle. Whatever the lifecycle, the main
testing phases are:

 Unit or Component Testing (CT): mostly done by the developers based on their
standard unit testing rules. Testing of interfaces, conversions, enhancement, reports,
workflows and forms (RICEWF) developed primarily with SAP specific (ABAP) code.
Including testing for security authorization, data transfer rules, reconciliations and batch
scheduling jobs. Business Warehouse testing is also part of this test phase. Typically
done in a development environment.
 System Testing (ST) or Functional Testing: ensures that your SAP implementation
meets your business requirements. SAP is a highly configurable system and can easily
be integrated with in-house applications or third-party tools. Given this highly
configurable and complex system, functional testing is a must. It removes uncertainty
over business use cases and brings quality. It includes reviewing design documents and
creating test artifacts like test requirements, test scenario’s and test cases. It is usually
done by a professional tester (or team) with a background in the SAP module being
tested.
 Integration Testing (CIT/SIT): testing of combined components (CIT) or modules (SIT)
of an SAP system to determine if they function together correctly. There are 2 types of
integration testing: Component- (CIT) and System Integration Testing (SIT). CIT is
typically done in a development environment, whereas SIT is typically done in a QA
environment with realistic test data.
 User Acceptance Testing (UAT): ensures that the SAP system is usable for the end
users. They independently execute the user acceptance test cases that include testing
business processes, functions, documentation (operating manuals, cheat sheets), etc.
Through UAT, users can become comfortable with the new business environment and
take full ownership of the system.

Test types
The most common used test types whilst testing SAP systems are:

 Regression Testing: done to ensure that the new changes implemented do not

negatively affect existing and working code. SAP is a tightly integrated system, a single
 stack update, OSS note, transport, configuration changes, or new developed interfaces
can have a cascading and severe effect. Usually executed using an automation tool by a
professional tester (or team).
 Performance Testing: ensures that the SAP system will perform well under expected
(high) workload. It checks its speed, scalability and stability by including load, volume
& stress testing to determine system bottlenecks. The aim is to enhance robustness and
help deploy systems that can sustain high load forecasts, with zero to little post-
production performance issues. It includes checking business processes that may cause
stress due to high transaction or batch volumes. It helps with conforming to SLAs,
optimizing software configuration settings, reducing overspending on hardware,
certifying the system will not crash or fail during seasonal high load and help avoid
corresponding financial losses. It is usually executed using automated tools
(like NeoLoad, a SAP certified solution with which Brightest has a partnership and
the expertise to implement it) & involves collaboration of basis, database,
infrastructure and a professional tester (or team) to monitor the results.
 Security Testing: ensures the safety of SAP systems. High risk areas like SAP-portal
security, network security, operational security, product security, access control and
source code are tested. This usually involves the basis, database, infrastructure,
development and a professional tester (or team).
 Portability Testing: involves testing the SAP-portals on different browsers while
checking the business processes.
These test types can be performed during any testing phase (described above).

Creating SAP test cases

Creating test cases for an SAP system is basically the same as for any software application
testing. To create effective test cases, you must:

 Determine the SAP role required to execute the test case

 Identify the SAP transaction that needs to be executed for the test case

 Define the Test Data required for executing the test case. And ask yourself if it needs to
be created, or is used by another tester, or is locked and cannot be modified.

 Define any (potential) prerequisites

 Have your peers (other test professionals or business users) review your test cases

 Create positive and negative test scenarios

 Describe detailed test steps to enhance reusability, common understanding and

prepare for test automation

 Make sure your test coverage is high

 Document defects as soon as they are discovered (according to agreed rules)

E.g. let’s design a test case to change the name of an employee in the SAP system:
Important note:
SAP is an enormous system with endless variations. It is neither feasible nor cost-effective to
check all possible variations and combinations of test parameter inputs in the system. As in
above example, a tester can verify the change in Last Name, Date of Birth, Address, Pin Code,
City, State, Country, change in permanent, temporary, work address, etc. The professional
tester can apply test strategies and techniques to reduce the number of test cases without
sacrificing coverage. Examples include boundary value analysis, equivalence partitioning &
orthogonal arrays. Often combined with test case automation.

Automated SAP testing

Testing is a huge challenge for a colossal system like SAP. As per recent study by ASUG, over
86% customers are concerned about risks due to lack of comprehensive testing.
The benefits of automation testing for SAP systems:

1. The first and most valuable benefit is the improved test coverage.

2. Better quality and therefore less production outages. Outages of SAP production
environments could cost a company millions of euros!
3. The workload decreases with each release cycle.
Automation Tools:
The methodology and approach are more important than the chosen automation test
tool. However, some examples that come to mind are SAP TAO, eCATT, QTP, S/4HANA Cloud
Test Automation Tool, etc. The choice of automation or performance testing tools for SAP
depends on the underlying SAP application being tested.