Adoption of DevOps requires enterprises to re-think their approach to quality in order to ensure that faster, more frequent delivery of code doesn’t increase business risk. In a highly interconnected platform like SAP for example, it’s vital that effective regression testing can be incorporated into a rapid delivery cadence. In today’s digital business it’s no longer acceptable to rely on risk-based testing – or perhaps no regression testing at all – in the hope that everything will be fine. But while it’s critical to test effectively, that’s not the only thing to consider when developing a quality strategy for DevOps success.

DevOps leads to more frequent delivery of smaller units of change. In general that means lower risk to production systems – after all if you’re changing less code, there’s less chance that something could go wrong. However, the typical length of a sprint cycle in agile development – a fundamental part of DevOps – might be as little as two weeks. Even with accurate forecasting and appropriate sizing of your sprints, that often leaves little time for a typical ‘develop then test’ approach, let alone the necessary rework and remediation when defects are found. This could be described as the ‘risk paradox’ of DevOps, and a new approach to quality is required to address it. To ensure the success of DevOps in SAP environments, we require not only an integrated toolchain for Continuous Delivery (CD) and Continuous Integration (CI), but also additional tools for Continuous Testing (CT).

Human dynamics can present a further challenge. Some QA professionals feel threatened by the concept of DevOps as they are worried that it will devolve responsibility for testing to developers and make their role redundant – a view refuted by many, if not most, DevOps professionals, I should add. Functional users, who are often critical to effective testing due to their expertise in business processes, see testing as a repetitive, non-value add activity that is ‘not their job’. Securing their support for more frequent testing for more frequent code delivery may be a challenging prospect.

Considering these challenges, the following five steps can help you to develop a quality strategy for DevOps success in SAP.

1. Shift quality left. The principle of ‘shift left’ is absolutely central to DevOps and underlies pretty much everything I’m talking about in this article. Rectifying technical errors as early as possible in the software development process not only reduces the number of production issues and business interruptions, it also enables a reduction in costs. Shift left is often closely related to the idea of automated unit and integration testing – as in this article, for example – but it can be expanded to cover things like moving ownership of failure from QA to developers, improving the quality of code that is being written, or in the case of SAP, employing automated analysis to resolve technical questions like sequencing and dependencies. Shift left also has the added benefit of reducing the burden of testing in the QA phase – and the associated rework and delays – leaving QA teams with more time to focus on the things that really matter.
2. Change your development approach. If you’re going to successfully shift left and implement DevOps for SAP there’s simply no option – some form of agile development is a must. It is the underlying means by which you can deliver at the pace expected of a CI/CD pipeline. There are different variants and approaches, but you’ll need to pick one that works for your organization. Be aware that adopting agile is about more than just delivering work in two-week sprints. For example, to be really effective you’ll want to implement backlog planning and refinement, peer reviews, retrospectives and a mechanism for measurement and Continuous Improvement as part of your development process.
3. Embed the QA function. DevOps success demands a cultural transformation, as well as a change in your technical approach. It’s vital to move from traditional ‘vertical’ teams where work is ‘thrown over the wall’ from one silo to the next (e.g. dev to QA) to horizontal teams where all disciplines are involved in delivery of specific business outcomes. That means your QA teams – along with Security, Ops and others – should be working together throughout the entire development and delivery process.
4. Adopt automation. DevOps is about operating at high speed. If you’re going to manage quality and risk effectively, that means you need software automation. Automated change management and automated testing go hand-in-hand as the fundamental enablers that underpin an increase in quality when moving at pace. Change control automation supports the shift left approach I mentioned in point #1, but regression testing can remain an intractable problem if approached in a traditional risk-based manner that requires the regular creation and maintenance of test scripts. A new approach, like that used by our Testimony product, enables you to fully automate your regression test processes so you can test more, at an earlier stage and do it more frequently, without the overhead created by test scripts.
5. Employ a flexible deployment strategy. The concept of Continuous Delivery in DevOps is all about being able to deploy code as soon as it’s ready and safe to do so, so that value can be delivered to the business immediately. But the high level of inter-dependencies and integration in SAP, combined with infrequent deployments in a traditional release calendar, make this a challenging prospect. How can the QA team know what they can safely approve for deployment if tests fail? Tooling like ActiveControl that allows you to employ a flexible deployment strategy, where frequent releases can be dynamically updated and delivered with confidence, can massively increase the efficiency of your QA process.

For more detail on the topic of quality in DevOps for SAP, join our upcoming webinar or request a demo for more information on how our software automation products can help you to implement a strategy for DevOps success.