Testing centers of excellence for agile: obsolete or opportunity?

Are testing centers of excellence (TCoEs) holding us back, or can they help us move forward?

thinkstockphotos keyboard question mark

Just a few years ago, global enterprises started clamoring to get testing centers of excellence (TCoEs) in place. In 2011, only 4 percent of organizations had TCoEs, but 80 percent wanted TCoEs. By 2015, nearly half of Global 2000 organizations adopted TCoEs—a staggering 825 percent rise in just four years. These TCoEs promised to increase efficiency by establishing a command center that was laser focused on standardizing software testing methodology, best practices, automation, KPIs, metrics and toolsets across the organization.

Then along came agile.

Even though agile adoption has been steadily rising for over a decade, it is just now reaching the majority of development projects in large enterprises. It is taking even longer to impact how these projects are tested. Usually, the focus is on development—until it becomes clear that you can’t meet your acceleration goals without transforming testing as well as development. As legacy testing approaches are (eventually) reassessed, the value and future of TCoEs are also brought into question: Are TCoEs holding us back, or can they help us move forward?

I believe that TCoEs can help transform your testing process for agile—but only if they first undergo their own digital transformation.

The structure of traditional TCoEs

Before we start dissecting what parts of a traditional TCoE help and hurt agile testing goals, let’s first focus on what a typical TCoE looks like. At the top, there’s a TCoE head, then a number of test architects and managers reporting to him or her.

Three additional roles then report directly to the test architects and managers:

  • Test design specialists: People in this role help the organization plan and define the optimal set of test cases. Although this is a proven way to increase test efficiency, very few organizations currently have specialists in this role.
  • Manual testers: These people manually execute the defined test scenarios and document the results at each step. This is, by far, the most common role in the TCoE. It is usually outsourced to global system integrators.
  • Automation engineers: In organizations that have achieved some level of test automation, these individuals are the ones responsible for defining and maintaining that test automation.

How traditional TCoEs impede agile

When organizations attempt to use a traditional TCoE to meet the new business expectations associated with agile, a number of issues tend to arise:

  • Latency delays testing: Testing does not begin until a project is completed and thrown over the wall to the QA team for testing. This means that developers don’t receive feedback until weeks or months after they’ve completed a development task. This latency complicates defect resolution, increases rework, and delays time to market.
  • Testing is too slow: With agile, the application is built (at least) daily and new functionality is ready to be tested every few days. Manual test execution simply cannot keep pace with the rapid rate of change. Month-long test cycles are no longer feasible once developers transition to Agile sprints, which are two weeks or shorter.
  • Testing and development are miles away: Agile expects testers to collaborate closely with developers in order to provide the rapid feedback needed to fail fast. Without colocation in a cross-functional team, testers have limited insight into the business and technical issues associated with each user story. Moreover, distances mean delays in asking and answering questions, reproducing defects, and so forth.

TCoE aspects that could help enterprise agile testing

Despite these issues, you don’t need to throw out the baby with the bathwater. Two primary TCoE benefits—standardization and governance—can be quite beneficial when introducing and scaling agile across a Global 2000 organization:

  • Standardization: Standardization of methodology and techniques is a proven way to increase efficiency. Standardizing on core test case design, test data design, and test automation practices—while still providing each team a reasonable level of freedom—significantly reduces overhead and waste. The resulting efficiency gain helps testers deliver the fast feedback expected with Agile.
  • Governance: To continuously optimize agile processes, it’s important to aggregate KPI and other metrics into a comprehensive top-level report that crosses business units. This is only possible if the various teams ensure that their unique metrics are compatible with higher-level reporting expectations.

Digital TCoEs: a new path forward

I’ve found that a new approach to a TCoE—what I call a Digital TCoE—enables enterprise organizations to satisfy the changing business demands associated with agile initiatives—without losing their grip on the standardization and governance critical for process optimization and scalability.

The structure of the Digital TCoE is fundamentally different than that of a traditional TCoE. Like before, you start with the head of the digital TCoE at the top, followed by a layer of test architects and managers, then some test design specialists and automation engineers that help the testers maximize the efficiency and effectiveness of their testing.

However, there is one major structural difference: You no longer have manual testers sitting in the TCoE. Instead, testers are operationally embedded in cross-functional agile teams (ideally, two testers in a team with five to six developers), but still reporting up to test architects and managers in the TCoE to ensure appropriate alignment and governance. The testers are fully supported by the TCoE in terms of tooling, training, technical customizations, and so on.

This colocation is obviously a big change for testers—but it pales in comparison to the changes in the type of testing they are performing. To meet business expectations for accelerated delivery and continuous quality feedback, test automation suddenly rises from nice-to-have to must-have. Simply situating testers next to developers is not sufficient; testing, as well as testers, must be an integral part of the agile team. This means that testing must become an organic part of getting each user story to “done done” rather than a late-stage activity tacked on every month or so.

In response, enabling rapid, efficient test automation becomes a primary goal of the core digital TCoE structure. Automation engineers become critical for guiding testers on how to automate testing, and test design specialists help them assess what specific test cases are most important to create and automate. Scriptless test automation tools reduce the learning curve and help testers, who are typically business domain experts (not programmers), make their testing efforts faster and repeatable. This enables the team to achieve the expected level of test automation without losing the domain expertise that’s critical for exposing critical defects—and ensuring that rapid, iterative releases do not ultimately compromise the user experience.

The digital TCoE <> tester relationship involves both give and take. On the one hand, the digital TCoE supports the testers in the agile teams from both a methodology and an automation standpoint. On the other hand, testers are expected to provide the TCoE reports in a standardized way so that they can be aggregated for enterprise-wide reporting—enabling governance for test results.

This article is published as part of the IDG Contributor Network. Want to Join?