So test who delivers in SAP

You could call it the "risk paradox" in DevOps: Even the most complex development projects are done in many small steps. This reduces the risk per release, since fewer code changes logically bring fewer errors.

On the other hand, the individual release cycles are so short that there is less time overall for quality assurance. As a rule, a sprint - i.e. one of many iterative work steps for the development of new functionality - including tests and deployment on the production systems lasts only two weeks.

In contrast, in the classic waterfall model, the development work is followed by an extended test phase, and only then is the release approved.

SAP developers and administrators have one fundamental goal: to ensure that what worked yesterday will work tomorrow.

This is as critical to success as it is difficult, especially in complex environments. Because here there is an almost endless number of dependencies, so that even small errors can have devastating consequences.

For DevOps to be a success in SAP environments, not only an integrated tool chain for Continuous Delivery (CD) and Continuous Integration (CI) is required. Rather, additional tools are needed for Continuous Testing. This is accompanied by a new test strategy in five steps:

First, the shift-left principle must also be applied to quality. Fixing bugs even before a new release goes live not only ensures fewer malfunctions and service interruptions.

Rather, cost reductions of up to a factor of 15 will be possible. For this purpose, however, tests would have to take place at an earlier stage of the project than has been the case to date.

Secondly, this has a direct impact on the development process itself. The new code must be tested several times during a sprint, not only in terms of completeness and functionality, but also in terms of its behavior in the production environments.

Peer reviews, retrospectives and measurements are also part of continuous quality assurance and allow for continuous improvement of the test procedures.

Third, this means that companies should embed quality assurance into their cross-functional DevOps teams and processes. Not only those responsible for operations, but also testers must be part of the DevOps team and participate in all steps of a sprint.

Because of the complexity of SAP environments, quality assurance threatens to become a bottleneck. That is why, fourthly, DevOps teams need the support of tools for automated regression testing.

Suitable tools cover virtually the entire production environment and therefore deliver results that are so close to reality that positively tested code can be implemented with a greatly reduced risk.

Fifth, existing SAP customers need a flexible deployment strategy. Depending on the test results, the project managers must be able to decide dynamically which changes should be transferred to the production environment at the end of a sprint and which should not. Here, too, they need the support of process automation tools.

One of the central promises of the DevOps concept is higher code quality. However, shorter release cycles alone are not enough to contain the risk of code errors in production environments.

SAP teams in particular must therefore make testing an integral part of their processes in order to make DevOps a success, even in complex environments. However, this can only be achieved with the help of an integrated tool chain that includes highly automated testing tools.