Cracking the code to a successful Testing Center of Excellence

I had an interesting discussion with some colleagues and clients yesterday about a well-known software testing organizational model; the Testing Center of Excellence.

The concept of a Testing Center of Excellence (TCoE) is steadily rising in popularity among many of the industry’s largest firms. Compared to only 4% of operational TCOEs in 2011 and 6% in 2012, research data shows rapid growth in fully operational in-house Testing Centers of Excellence to 19% (World Quality Report 2013-2014).

Centralizing software testing teams under the auspices of one organizational leader can introduce financial and productivity economies of scale. However, this operational model does not come without its challenges. For organizations that are in search of operational efficiency, a TCoE is often perceived as a panacea for software testing and quality. While it absolutely resolves numerous issues that stem from a distributed approach to software testing, it does have its shortcomings. Without awareness of these specific vulnerabilities, the TCoE will never mature to its desired level of operation.

The most elusive and damaging shortcoming is what I refer to as a lack of “Role Overlap”. TCoEs are extremely efficient at consolidating specific testing skill sets, leveraging those skills across multiple projects and driving productivity from same-skill team members. However, inefficiencies crop up when the TCoE team members engage development and business teams.

When members of a centralized TCoE are required to work with development teams to review requirements, conduct defect investigation and take joint ownership of product quality, the TCoE model as it operates today reaches its limits. For example, when two different organizations are required to work together, it doesn’t help when neither speaks the others native language. That is precisely what a global organization encounters when development and test teams attempt to collaborate to resolve problems. Generally speaking, and for the majority of occurrences, testers and developers not only possess different types of skills; they require different kinds of people to do the job. Further, the manner in which the organization is structured unknowingly creates and contributes to this inefficiency.

Quite often an organization decides to centralize its software testing as a ‘service’, and in the majority of cases, its testing organization organizationally centralizes all of its testing resources under one leader.

In this operational setting, the testing capability is folded under an umbrella ‘Center of Excellence’, as the development teams are then left to their own degree of organization; a “like-for-like” model. What this approach fails to accomplish is an effective method for communication and shared ownership of quality.

While on the surface this appears to be a model of efficiency, the devil is in the details. Operating in this model can result in numerous inefficiencies such as:

• Unit testing is regularly insufficient
• Lack of vested interest in testing
• Testers and Developers don’t speak the same “language”
• Developer-skilled resources are required to do basic defect trouble-shooting
• Developers desire to “move on” to the next project
• Defect misinterpretation

These inefficiencies will result in:

• Immature test operations
• Cost overruns
• Schedule overruns
• Questionable levels of Quality
• Inefficient use of project funding
• Low morale among team members

Combating this well-hidden barrier to achieve higher maturity requires not only a change in how the teams operate, but most importantly in how they are organized. The manner in which a team is organized drives how they behave.

The secret to this new approach is placing a test engineer(s) within the confines of the development (DEV) team. This is more than just assigning a tester(s) to do component testing. Very specifically, the test engineer will be co-located (virtually and/or physically) with the development team – not the TCoE. This test engineer will embody the spirit and culture of the development team and truly become ‘one of the team’. This role will have a matrixed reporting to the development manager as well. Yet, however –and most importantly- is a true member of the TCoE. This role has a hard line report to the TCoE leader and is the representation.

In addition to the organizational and location shift, this test engineer will be expected to conduct a different type of testing. This role will take ownership of the quality of the software code as it leaves the development team; not the developers. Test engineers are accustomed to having Key Performance Indicators (KPI’s) associated with ownership of quality. Developers typically do not (outside of the world of agile development). Hence, the software is being delivered to the TCoE, not by the developers, but by the tester within the DEV team – the right role for taking ownership of quality. This is a fundamental paradigm shift. In order to accomplish this shift successfully, the DEV-based test engineer will be expected to do different testing from what the DEV team traditionally takes ownership. These types of testing include:

• Component testing (white box testing)
• Sub-system testing (white box testing)
• 1-up/1-down integration testing (white box testing)

This test engineer will also take on responsibly for the following:

• Single point of contact for all TCoE communications with the DEV team
• First line of response for defect management representing DEV
• Quality of the software code delivered to TCoE

The positive effects of this simple change can be sweeping. Not only can it result in higher quality code and more efficient testing, but it can also help to build bridges between DEV and TCoE that may not currently exist.