The Test & QA Temperature: Role Overlap – The missing component of the Testing Center of Excellence. A road to higher testing maturity

Publish date:

Hello everyone….I had an interesting discussion with some colleagues and clients yesterday about a well known software testing 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 […]

Hello everyone….I had an interesting discussion with some colleagues and clients yesterday about a well known software testing 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%[1]. Centralizing software testing teams under the auspices of one organization can introduce financial and productivity economies of scale.  However, this operational model does not come without its challenges.  For many 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 elusive and damaging shortcoming is referred 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 confines of the TCoE are departed. 

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 other’s 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 confusion.
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 like 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 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.  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[2])
  • 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 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.
That’s it for this post.  Keep an eye on my blog as I share thoughts on upcoming topics including ‘tool v. process’ and ‘getting metrics right’.  Until then….”trust, but verify”.

-Dr. Kapfhammer

[2] White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing). In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases.

Related Posts


Delivering faster with better use of micro-frontends in financial services

Date icon September 21, 2021

What works well is multiple SPAs owned by specific DevOps teams that can decide what happens...


Sustainable experiential banking – are banks ready?

Elias Ghanem
Date icon September 7, 2021

To prepare technologically for Banking 4.X, banks must evolve legacy systems toward core...

Financial Services

Who needs high-code developers? Citizen development is here for Financial Services

Date icon July 22, 2021

Why does IT let business wait for months to deliver low-hanging fruit process improvements if...