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-premises as in the cloud and is suitable for large, as well as small and midsize enterprises (SMEs). There are mobile apps 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. 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 them 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 switch 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 need to learn the customizations made by the client, but this is a huge advantage.
Maintenance
Maintenance is a big part of SAP testing, also 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)
Developers do this mostly 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
This 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. Usually a professional tester (or team) with a background in the SAP module does this.
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)
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
We do Regression Testing 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 a professional tester (or team) executes this using an automation tool.
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. Besides that, it involves collaboration of basis, database, infrastructure and a professional tester (or team) to monitor the results.
Security Testing
Security Testing assures 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
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
- Did 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)
For example, let us design a test case to change the name of an employee in the SAP system:
