SAP has been around since 1972 and is arguably the largest company and solution provider for business processes. As SAP usually manages a larger company business flows in finance, supply chains, plants etc. the applications are of really high business critically.
We will in a small series go through a number of topics regarding SAP and testing using our experience in both SAP and the non-SAP space.
High risks means that immerse testing is needed, but in too many SAP projects, testers and testing is absent or too much down-prioritized.
Those saying that testing is not needed in SAP might argue with the following statements:
- SAP has already tested the software.
- We are only using standard programs within SAP.
- We know how to write ABAP.
- Testing is made by our functional consultants.
Even if SAP has tested the SAP software, they have never tested in your environment, with your data, your roles, your integrations and IT environment to name just a few things.
In the end, there are thousands of database tables with million of rows of code that must work to make your business to run.
Therefor a normal risk based strategy is a good choice to start your SAP testing planning. We will go through a simple way to conduct it from a high level perspective in a later post.
When you have collected the risk analysis, which might be that you need to perform in an iterative way, you can start to break down what kind of testing, resources and competences that are required.
If you are working in an update/upgrade project, you might consider using the in-built tool called Business Process Change Analyzer (BPCA), we will discuss that more in a later text.
Another thing, that differs in SAP in comparison to many other platforms are environments and the concept of transportation. In a larger SAP project you might have a developer environment where developers are testing, an integration environment, a test environment, a QA environment and a production environment. When installing the changes, in the environments, the code is ”transported” from one environment to another. Usually this is performed in SAP own tool called Solution Manager (Solman).
Typical 3-system SAP landscape
As SAP production environments are very powerful and expensive, the other environments usually don’t have the same performance, data or integrations as production. The closest environment to production shall always be the QA environment, and if you can afford it, it’s shall have the same capacity as production.
Data is also something to consider early on. What kind of data, how much data and the data spread that the tests need is a few of early considerations. When testing SAP, data in many cases are consumed and can’t be re-used as SAP is keeping transactional data referenced. There are tools available to copy data, but even with them it can be cumbersome to deal with test data.
Integrations to other internal or external systems, needs to be carefully planned due to the availability of the integrations. In some cases you also need to setup the other receiving side to be able to test your system toward another system. In some other cases the connecting system is not available or has a high fee to use. Sometimes, you don’t have testing environments for integrations at all. Concepts as one-cent tests (transfer least amount of money, stock, data etc) could be a wise approach.
In SAP there are a few terms that is good to know, such as IDOC which is a SAP object facilities information exchange. BAPI, which is an interface for synchronous two way communication. As SAP evolves, concepts as java connector, SOAP, REST and using cloud computing might be available as techniques in your SAP environment, but they are not unique for SAP in any way.
Planning risk early for integration is a good advice, as you might need to have a plan B ready for environments and integrations (and it’s data).
Special supporting environment might be needed, such as own mail server, so that your testing is not starting chain reactions in or outside of your company.
Reports and business intelligence is usually a key feature for the stakeholders. Even if the ”technical risk is low”, you might consider testing important reports with a filled database to find out if the ”daily batch of reports” are delivered in time. We have experienced cases where a daily report took over 25h to run, meaning it was meaningless for the stakeholders to take appropriate decisions. Reports that are wrong can also have very nasty effects for the company and could even be illegal (finance reporting to stock markets etc.).
Many companies have migrated from Oracle db:s to SAP own HANA database to fasten up performance in the last few years as the solution could not cope with reporting and transactional performance. HANA is a memory-based database completely written for SAP applications.
The last topic in this post will be regarding security and roles. As the SAP system contains very important and valuable data with many integration and users. You must consider taking this into your planning. Who should be able to see which data/program/reports, who should not be able to execute certain data and how can you make the environment safe of breach.
A testing challenge in this might be when you are doing acceptance testing, that your testers (preferable key users) can’t test due to that their role has too low permission levels. As the change need to be transported to test environment, this can severely hurt your time planning. As a hint, there are tools available that can raise an ”issue” and temporarily raise the permission level, so the tester can continue to test.
Testing in SAP is very similar with testing in any other large business solution, but there is a number of own terms, tools and concepts that are different and to support this challenge SAP tries to improve it’s test process with better tools such as BPCA, Scope and effort analysis (SEA), Test Data Migration Server (TDMS).
As a non-SAP person coming into the SAP space, it might be a overwhelming experience, but as in every large system, try to break down the areas, tasks, functions etc. into smaller pieces while understanding that your job as a tester or a test leader might be to coach your fellow colleagues. Be patient and try to use their knowledge to find an approach and a scope for your project.
This is the first post of several. We will go into details on a number of topics, so stay tuned!
//Bengt Augustsson
Bengt has worked over 20 years in the testing business and is a co-founder of QualityMinds.