It was eloquently put by someone I recently worked with "How do I know the change I just made didn't break anything?"
Read any book on software development best practices and it is likely to mention, or maybe wax lyrical on, phrases such as unit tests and test driven development. It may even mention continuous integration, automated acceptance tests or integration tests.
Why is automated testing so important?
The answer is for exactly the reason in my first sentence, every change that is made to the code or configuration of a system is likely to have an effect. After all, that is why you made the change, right? The goal is to ensure that after your change, 1) the product doesn’t crash, 2) it still performs the required task and 3) still meets the requirements of the client.
Traditionally, SAP projects have had a heavy testing phase to ensure these three things. This phase is expensive in time and resources because manually creating and executing tests is a very laborious task.
The large SAP CRM/ SAP ECC project I’m currently working on involves many consultants who will test and develop the solution over the course of the year. We are currently at the testing phase. The solution is built. The documentation is there and all we need to do is prove that it works. This process is manual. We are using standard SAP CRM functionality but have to test it manually.
What if I said you could do this automatically and quickly? Input unit tests, perform integration tests and acceptance tests and have the system test the product for you in minutes rather than weeks? Then, re-run these tests after each and every code or configuration change? Regression test solutions with the click of a button? And scale the tests in parallel to test system performance?
Why can’t we perform automated testing now?
SAP NetWeaver has built in code unit testing and ability for large scale scripted testing but these are not used by most components. Code that doesn’t have unit tests built when it’s written usually causes issues when writing the tests later on. Writing tests at the same time forces good code design to ensure the system can be tested. If you don’t think about testing when you build a system, it is difficult to bolt it on later.
There are also no built-in acceptance or integration testing suites for SAP which means that SAP ECC, SAP CRM, SAP BI etc. don’t have delivered tests out-of-the-box. And this means that you may prove the individual components work correctly, but testing the solution hangs together as a whole is still largely a manual process.
Enter SAP HANA
It is true that legacy SAP ECC, SAP CRM and SAP BI applications will work on HANA but, for the most part, they need to be updated to take full advantage of the different design paradigm that SAP HANA brings to the table. This work involves performing calculations at the database level rather than on the application server to get a sizeable performance increase.
What’s more, new solutions can be engineered for SAP HANA. Originally necessary to replicate data into different formats to different systems for recording, reporting and analysis across the landscape. For the first time solutions can be designed on the “single source of truth” principle. No longer requiring costly replication of data, a traditional barrier for automated testing, making the solution and testing that much simpler.
My ask of SAP
If you need to optimize some of the core applications for SAP HANA, or build new applications, build with fully automated tests, share the tests with your customers and allow extensions and new tests to be added as we enhance the product to meet client specific requirements.