Decoding Disruptive DevOps for QA – Solving the TCoE Conundrum

Source – cio.economictimes.indiatimes.com

In order to accommodate the wave of digital technology sweeping across the business world today, organisations must constantly operate in an agile and DevOps mode. This can help to ensure faster release cycles and foster closer collaboration between various teams. This digital transformation also means that IT environments are becoming ever-more complex, as businesses look to cater to next generation technologies like cloud, mobility and analytics. All of this taken together means that it’s often a challenge for organisations to balance innovative technologies with cost efficiency.

This is where Quality steps in. In order to keep up with changing times, traditional Software Testing has evolved into a Quality Engineering and Assurance function, serving to ensure Quality is baked into every stage of the Software lifecycle. This eliminates the need for a dedicated Testing phase at the end. In turn, this not only means faster time to market but also represents a key lever for reducing CAPEX and optimizing OPEX, which aids cost reduction.

Many leading IT-driven organisations, especially in retail and financial services, feature a traditional Testing Center of Excellence (TCoE) or dedicated QA Services Group to ensure standardisation, modernisation and the adoption of best practices and innovative processes. Often these CoEs have evolved over time, undergoing three distinct stages:

• Stage 1: Serving as Resource fulfillment centers
• Stage 2: Operating in a committer model, with the main aim of optimising resource utilisation and increasing enterprise level adoption of best practices
• Stage 3: In this stage, TCoEs act as technology and solution innovation hubs, and best used for level 3 problem resolution.

The majority of organisations that have adopted hyper-automation, operate in stage 2 mentioned above in which they follow the committer model. In the committer model, CoE teams act as Hit Squads. They approach different projects with a specific goal ranging from increasing the level of test automation of an engagement, to the adoption of specialised services such as service virtualization. After this, they continue working on their central innovation pipeline. This also ensures that cost of the redundancy is contained. The committer model is a very successful way of working and the model can be extended to implement integrated DevOps toolchains faster. However, due to the lack of understanding of what DevOps truly implies, TCoEs are usually looked upon as contributors to DevOps rather than enablers of DevOps. Owing to this, independent DevOps innovation centres or Centres of Excellence are created instead of existing TCoEs being empowered.

To elaborate on this point, most organsations today that incorporate DevOps in their IT tend to skip important steps such as assessing their agile maturity or landscape technology readiness. This lack of preparedness or information about the implications of the methodology itself, very commonly leads to a majority of organizations setting up an independent/separate DevOps service line, decoupled from their existing QA CoE setup. In the process, they end up investing more than time and money than they should in order to reach their target state of IT nirvana.

In multi-vendor scenarios where multiple development and QA partners work together in the same application landscape, this model becomes even more crucial. In such cases, the concept of DevOps cannot just be a one-time implementation; rather it needs to be enforced in form of standard processes and governance in the way described in Stages 2 and 3. Other strong reasons to add DevOps to QA CoE’s portfolio include:

? Developing in-built emphasis on Quality Assurance, which is often missed by Developers
? Coupling BDD frameworks as Build tests to form lean SDLCs for a leaner DevOps implementation
? QA CoEs tend to maintain most of the metrics necessary for assessing end to end automation levels of an organisation
? A strong focus on NextGen offerings with a keen focus on offerings focusing on Shift Left such as Service virtualization, QA CoEs can provide insights to create lesser infrastructure footprint in QA environments which can also be extended to Dev environments

It is often argued that Agile Transformation teams should manage DevOps roadmap and adoption within organisations. They do tend to be more suitable than QA CoEs in many situations, in particular where safe adoption is to be coupled with optimized tool chain for quicker DevOps adoption. However, transforming the TCoEs into a DevOps Innovation Center is a better alternative, especially when organisations tend to have small pockets of excellence and a stronger focus on transforming existing teams rather than bringing in new teams.

To summarise, if an organization wants to implement DevOps as a discipline, they either need change agents like Agile transformation teams or alternatively onboard completely new teams to overhaul the process. However, for the best of both worlds, if QA CoEs already exist then they need to be empowered to be the governance and support layer in order to properly fulfil an organisation’s DevOps objectives.