How to apply Continuous Testing in SAP
With the goal of accelerating the adoption of new technologies without affecting business continuity, the journey of digital transformation in organizations increases the pressure for automation at all stages of the software development lifecycle.
One of the most commonly squeezed steps for reducing time and cost is software testing. For traditional development models, according to our experience, about 32% of the time between the design and the entry into production of a feature is spent on software testing. Therefore, automating this process to the maximum is mandatory.
Even for major exponents of the software development world, such as SAP, this reality is no different. Test automation plays a key role in enabling the deployment of agile development (CI / CD) and DevOps and can get the new functionality to come into production in the shortest time possible.
However, some challenges prevent the deployment of large-scale test automation solutions:
SAP Functional Knowledge
With the lack of functional analysts to perform the tests, test coverage is often impaired. Specific business cases may be left out of the test due to lack of functional knowledge in modules and business processes.
Mass of Data
Creating mass data to allow you to test specific situations is also a great challenge for teams. Although there are several solutions for copying or subsetting production data, finding the mass of tests and maintaining this valid mass remains one of the great challenges of the tests carried out in the SAP platform.
Integrations with legacy systems
For the vast majority of SAP implementations on the market, integration with other systems is a major source of defects. New implementations at either end require a new series of functional tests on the platform, to ensure the correct functionality of the functionality.
Maintenance of Test Automation Scripts
Because test automation uses the system components, every time these components change it becomes necessary to update the automation scripts. Therefore, systems that have a high degree of update or evolution (and consequently need a greater coverage of tests), demand a higher percentage of maintenance of these scripts.
Given this scenario, it is the main question that this article proposes to answer:
How can we implement a continuous testing framework for SAP?
The solution to this question involves the implementation of a tool called Testimony from Basis Technologies.
New Paradigm
Instead of running scripts based on automated scripts, the Testimony tool creates tests based on the capture of production transactions. This technique allows for 100% automated and continuous regression testing.
Truth?! How it works?
- Discover: In the first phase, a listener is installed in production. It uses SAP's own technology framework to capture transactions.
- Learn: All transactions, data and integrations performed by SAP in a given period are captured and masked to ensure the safety of productive data. At this stage, you can use dozens of filters to capture only parts of the transactions, if desired.
- Setup: At the time of testing, a new virtualized environment is created exclusively for this round. The data captured from the production, and already masked, is copied. Legacy system integrations are virtualized as captured inputs and outputs. Finally, a merge is made between the changes made by the development team and the version of the application that is in production.
- Validate: To validate if the system continues to run, the tool re-executes all selected transactions (10% to 15% of the production runtime) in the new unique testing environment (which has all the data and virtualized integrations required to the tests) and points out the differences between the result obtained in the production and the result of the tests.
Wow!! That sounds pretty cool! When can I use it?
- Upgrades / Updates: SAP updates are great scenarios for using the continuous testing paradigm to validate whether business modules and processes continue to function properly.
- Migrations (for Cloud or Hana): Migrations also require a lot of regression testing and is an excellent case for using Testimony.
- Development of new features: Even new developments require a considerable degree of regression testing. The new changes must be tested using the traditional method, but the impacts of the change can be tested using Testimony and, after being deployed in production, the new changes will turn into regressive tests for the next deliveries of the project.
- Production Support: Testimony can also be used to investigate problems that have occurred in production and need to be reproduced in the controlled environment for problem analysis purposes and retests after correction.
Interesting! Are there more benefits?
- Less Costs: Reduction of change costs by up to 50%.
- More Deliverables: Deliver projects up to 50x faster
- Less Manual Effort: Manual effort reduction by up to 95%
- More Quality: Reduction of incidents by up to 50%
Written by: Rafael Nóbrega
Head, Digital Products - Inmetrics
MSc in Computer Science from the Federal University of Pernambuco (Brazil).
Technical Management Program from University of California (USA) and
Leading Product Innovation from Harvard Business School (USA).