5 Best Practices for SAP Data Testing

Let’s talk about SAP testing. 

Super fun huh? Oh, the trials and tribulations of SAP testing. All of us that live and breathe SAP know that testing takes up a lot of time and requires the right data to shorten that cycle. Regression testing can be a word you don’t want to hear. But, it’s a necessary and critical part of an organization’s IT landscape. Testers are looking for errors while trying to keep security breaches at bay.

Did you know that 35% of a large enterprise’s IT budget will go directly to testing¹? That’s a lot.

SAP data testing is complicated and it has its share of challenges.

SAP test data challenges

We recently did a webinar on SAP Data Testing best Practices Dos and Don’ts, and we learned a lot from this webinar about what people’s biggest challenges are with regard to test data.

Time and time again, we hear from our customers how running various projects at the same time brings complexities and challenges to their SAP landscape. They complain about testing complications and the lack of good quality test data.

Here are the most common SAP test data challenges we found:

1. Reproducing production issues in non-production systems
2. Refreshing test environments
3. Insufficient test data to support testing needs
4. Securing sensitive information

Adding to these challenges, check out this stat from NIST:

So...to manage these challenges, here are 5 best practices for SAP data testing:

1. Matching the data volume to the need. A lean copy of a system vs. exact copy of a single sales order
   
   When provisioning data for testing in SAP, it’s important to consider the types of testing that will take place with the data. If the data is being established in a unit testing client in development then the volume can be small and isolated to the specific process to be tested. There’s no point placing large volumes of data into a development system, which is not intended or suitable for performance testing. When looking higher up the transport path, individual data sets will be ok for production support issues and in some cases integration testing, but most organizations will have some performance testing requirements before going to production. We then need to look at client subsetting if a volume of master data (e.g. all Customer masters) will suffice for the testing, or in some cases we may need a partial or full history of transactions also.
   
   
2. Ensure that production data to be copied does not impact other testing and procedures
   
   Many of our customers, particularly those in FMCG and Retail, come to us when they have a requirement to update some testing data, without damaging other data. Some parts of a Material master may have been updated in the test system, for example, extending the material to a new plant. This cannot be overwritten but the testing cannot carry on without the latest pricing conditions or new vendors/customers which have been recently created in production. This requires laser-like precision in the identification of data and filtering options chosen.
   
   
3. All test data should be compliant with security policies – sensitive data can be masked without reducing its testing value
   
   Data Security will be by far the biggest IT story of 2018. By intelligently masking labels and identifiers, real data can be used for testing and the richness of data variety maintained. Without that capability companies will revert to asking the tester to create the data. The dangers there are the person testing brings their preconceptions to the testing and also the data. Unusual data cases are often the ones that surprise us in testing and highlight difficult to spot bugs.
   
   
4. Good testing processes are repeatable and where possible, automated
   
   The rate of change for business is forever getting quicker. Manual testing is costly, can be prone to error, and time consuming. To enable business agility testing must become quicker and easier to schedule. With 35% of large companies IT budgets going on testing there must be benefits to be gained through more automation of testing.  
   
   
5. Create simple, focused test scripts specific to the change being implemented
   
   If the data and exact testing process can be identified and recorded there is a simple consistency and repeatability to the testing. Once an organization has a catalogue of repeatable test scripts the reliability of development goes up, and the automation becomes much simpler, allowing manual testing to focus on the new or complex/critical cases.  

There you have it. When it comes to SAP data testing, there’s a lot to consider. If you want to find out how to automate your testing system, check out our easy-to-use solution that will alleviate your challenges.

What SAP data testing challenges have you come across? Respond below in the comments!

Sources:

1.  https://www.kms-technology.com/blog/testing/companies-spend-35-of-it-budgets-on-qa-and-testing.html