Skip to main content

Change in Approach to TCoE in the World of Decentralized Testing in Agile & DevOps Strategy

A decade earlier when clients started looking for a highly standardised QE practices (either for a specific need or a very complex business need) and aim to build a centralised repository of reusable test assets and artefacts to deliver quality at optimal cost through optimum utilisation of resources, they started building Testing Centre of Excellence (TCoE) Services.

With constant change in SDLC models and methodologies due to agile /devops strategy, in past half decade clients have leveraged centralisation and decentralisation of TCoE services. Below is an illustration of our change in approach to TCoE due to decentralisation of testing.


* DQO focuses on more holistic approach in improving delivery performance viz. earlier defect prediction, faster response and reduce cost of experience

As testing service teams decentralize and grow more fragmented, it becomes increasingly difficult to maintain control over epics and deliverables and to manage centres of excellence. Specifically test team structure has moved from a highly centralized group responsible for all testing, to testing centres of excellence, to digital testing centres of excellence, to testers being embedded within Agile Dev team structures.

Now, Test teams (like Dev teams) are shifting toward more of a federated model that’s largely decentralized but has shared and centralized components available to test end-to-end interactions along with testers integrated in agile / devops teams.

Now this doesn’t state that “Federated TCoEs” don’t have any part to plan in this constantly changing environment. Below are few pointers which provide enough evidences, that Federated TCoEs merge well with DevOps and provide immense benefits. Also, this merger of TCoE with DevOps teams is a journey from “TCoE” to “Practice Centre of Excellence”:

  1. Domain competency enablement: Capability buildings can be challenging in DevOps model; however centralised units can bridge capability gap by building centralised domain capabilities and more mature R&D teams.
  2. Test coverage assurance: Due to rushed deliveries and continuously changing application DevOps alone doesn’t provide full test coverage, however having a centralised approach e.g. RBT (Risk Based Testing) in place can mitigate challenges related to test coverage. Identifying what needs to be tested across the board quickly, sharing observations and gauging the improvements that need to be made.
  3. Tool standardisation enablement: Implementing the best practices using well researched and scenariospecific tools that will not only speed up the testing process but also help involved DevOps teams to focus on other essential needs.
  4. Non-Functional assurance: When DevOps teams are focusing more on quick functional deliveries, at the same time Centralised units can research and focus on NFRs, so that DevOps teams can provide E2E quality factors which can further factor into overall quality.
  5. Harnessing automation patterns and AI/ML in QE: As we know that automation patterns, AI/ML in QE and best practices are the key to success for testing services, without patterns, maintainability, quality & timely deliveries and retrieving ROI can become challenge for any DevOps project. Centralised practices can bring such standard and practices closer to DevOps teams to help them to increase efficiency.

In summary, modern pipelines and data trends in agile / devops have led to five-fold decentralisation of testing objectives. This has changed our approach to TCoE from Centralised to Federated enabled by our differentiated service offerings to achieve decentralisation objectives.

change 2


Let’s engage