How do you find the sweet spot in Quality Engineering?

Within an agile context, responsibility for quality is a joint responsibility of all team members throughout the entire chain. This also holds true in SAP environments, where many 'teams and streams' are involved. Therefore, many organizations focus on delivering 'Quality at speed’ but struggle to find the right balance: they do feel responsible for quality, but due to the pressure of a fast time-to-market, speed still takes precedence over quality, with all its consequences.

Neglecting and removing responsibilities for quality has major consequences: no vision, no focus, no ownership and the long-term risks that drive business value to diminish - along with business support and credibility. In other words, ownership of quality is crucial in IT - and SAP- programs.
In this blog, Bert Linker, Sr Agile Quality Consultant at Sogeti and Pepijn Paap, SME SAP Quality Engineering at Sogeti dive deeper into this issue. In doing so, they outline the context, look at the different facets of software development and testing and focus specifically on SAP environments and agile development - two areas where many different, cross-functional, and cross-cultural teams are involved in delivering quality.

Part of the DNA

To find the balance in Quality Engineering, you must first define what you as a team and organization understand by Quality Engineering. Bert Linker, Sr Agile Quality Consultant at Sogeti explains: "Quality Engineering requires an overarching approach. People inside and outside your team need to understand why quality is so important and also propagate this Quality idea." This applies not only to developers and testers, but also to the business. "Everyone needs to take ownership of Quality Engineering. And only if senior managers and stakeholders also support this way of thinking then Quality Engineering can become part of your DNA." 

Prerequisites for quality

How do you ensure that thinking about quality seeps into the capillaries of your organization? "First, it requires a cultural change in which everyone knows and strives for the importance of quality. Quality Engineering must be incorporated into the 'Processes' and 'Products' alongside the 'People.' In addition, you need a clear policy on quality to ensure a consistent approach. Last but not least, you need to find the balance between speed of development and quality of product and process," says Bert Linker. "This applies to SAP and DevOps teams, or regardless of which IT delivery model you use."

Sweet spot

When determining the Quality Engineering sweet spot, you have to consider three aspects: the speed of software development, the quality of the final product and the quality of the software development method. "The latter is sometimes forgotten," says Pepijn Paap. "Developing in the right way ensures that your software is easily maintainable, scalable and you can easily adapt to changing business needs." However, it is not always clear who has ownership of these three aspects. Who is the owner of the software development process, who owns the final product and who owns quality?

Owners must have aligned these aspects properly, define clear choices and ensure that these choices are secured and adhered to. Ideally, these three aspects come together integrally in the Quality Engineering sweet spot. You can visualize it as three circles that are overlapping. The common denominator, the area of overlap is your sweet spot.

_{[blog continues below image]}

Pay attention to DevOps and SAP

In modern IT delivery models such as DevOps and Scrum, pipelines and End-to-End tests are often complex. The same holds true for SAP environments. That requires extra attention for Quality Engineering. How do these End-to-End tests run and who is the quality owner of it?

"End-to-end testing rarely proceeds in one straight line. It is more like a labyrinth, a complex maze with different turns, parallel roads and intersections. Sometimes you also have to make a U-turn and take a step back in the process," explains Pepijn Paap. That raises the next question: where do you start implementing quality measures? "In a complex End-to-End test, like in an SAP environment, it's recommended not to start at the first step, because then you don't really know where you will end up. Tip: Start by defining the output of the End-to-End test first, for example for Finance. For instance, what does Finance want to validate and verify? From there you work back and define the test data needed in the End-to-End process."

Focus on quality, encourage ownership and work backwards in complex End-to-End tests are some general tools to improve Quality Engineering and discover the Quality Engineering sweet spot. Often, reality is challenging and recalcitrant. Organizations are set up differently and operate in their own way. Within any overarching agile cross-team approach and in any SAP environment, additional complexities such as stakeholder management comes into play.