Relieve business users from testing
Migration of SAP systems to HANA is one of the most pressing tasks for more and more companies. SAP BW was the first application that took over the advantages of in-memory database and today more than 50% of SAP BW customers have moved to HANA. Those who haven’t migrated yet often face a whole bundle of projects even more complex than the migration itself, such as a Unicode upgrade, data center change, migration to cloud or major release upgrade. However, with migration to HANA, the transformation of BW systems is not even close to being done. There are more changes coming such as DSO to ADSO migration, 3.x loads migration to DTPs, front end migration (BEx 7.x is not supported anymore on BW/4HANA) and the migration to BW/4HANA itself. So, there are a lot of changes coming. So how to secure against bad data quality after migration? And who is in charge of testing and data lineage?
What if no testing is done
You may argue that nothing could go wrong during the change, or that the system is not mission critical. If a problem occurs, data is fixed through a reload. Still, the main purpose of the BW system is to support decisions. If data is wrong or users have doubts about its correctness, the core purpose of the BW system is questioned. What is the value of an analytical system without reliable data? Zero. Furthermore, these scenarios are very different from a standard upgrade, and they are done in each organization once. That is why the team doing it is not so experienced and needs an extra safety net.
What needs to be tested?
Testing of analytical systems differs from testing transactional systems (such as SAP ERP). From a business perspective, the only thing that counts is that data is correct. In HANA transition and related scenarios, this is mostly secured by data validation – is the data the same as BEFORE? Secondary parameter is the speed, where of course users with HANA have high expectations. Data validation is different than standard testing. It requires comparison of before image and after image, along with thousands of data records to be compared for every query, for the complete system. It is a simple, but due to the amount of data, tedious and time-consuming exercise. You may say that testing of ETL is easier – run the process chains and see if they all come up green. But again, it doesn’t mean the data is correct – so we are back again to data validation.
Who is going to test it?
The typical choice for IT is to involve business users (same as done in the ERP). However, business users don’t see any added value in many HANA related changes. What is the value for business of migration DSO to ADSO or 3.x to 7.x loads? And consequently, if there is little value to the business, the business should do only little bit of testing. In the case of ERP, IT does not know the processes. In BW, test scenario is quite simple which means IT could do it with the skill set they have. In the ideal world, the testing should be driven and fully done by the IT, while the business should be only in the steering committee, understanding possible issues and giving a GO/NO GO decision for going live. However, IT has never enough resources and budget.
Catch-22 – how to solve it?
The IT has an unsolvable problem:
• Changes to the BW are a must – with SAP HANA there are many changes from SAP which are forced (e.g. systems will go out of maintenance, new functionality only for ADSO etc.)
• BW migration / change must be tested on data correctness, because that is the main purpose of BW system
• The number of queries is so big, that the complete testing would require unacceptable costs and efforts
• IT has the capacity to do only basic sample testing, however they don’t know exact parameters the business is using in queries
• Business involvement should be as little as possible, mainly on the steering committee level
The only choice out of this problem is to automate the data validation. Standard test automation solutions are built for transactional systems such as SAP ERP. Since the testing is very different also the solution must be different. That is why we have built Datavard Validate – a solution that can automate data validation in SAP BW. It can gather information about how users used their queries and then use it for test case generation. The complete setup it up takes only several minutes, so it generates the value immediately.
• Due to HANA there are more and more changes required for analytical systems – this will not change any time soon
• Testing of these changes should not be done by the business, since they often bring very little value to them
• Big part of the testing (data validation) can be automated, but not with the traditional test automation tools
• Datavard Validate was built specifically for data validation and can bring huge value in little time, ensuring that all the testing can be done by the IT, with little business involvement