Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Thinking about Testing Centers of Excellence

Posted on: 27 April '10

Any company worth its salt can do anything that a TCoE can do. So why start a TCoE (Testing Center of Excellence)? The best reason is this: there is strength in unity. TCoEs are all about standardization and centralization, which can integrate the testing of very diverse portfolios of applications and systems.

Silos erode profits. When production teams operate in silos, profits decline due to ignorance and complacence. (Think of it in its political form, balkanization: a balkanized region is vulnerable to conquest because of divided interests.) Shared Services (internal) and TCoEs (external) can remove barriers to process improvement across multiple groups, and enable resource-sharing that siloed groups cannot even dream of. Centralized operations allow greater flexibility and scalability, common reporting of project management metrics, and independent testing. But internal re-structuring for centralization tends to be politically divisive.

Many companies don’t want to do the work of preparation that is required for TCoEs. They will focus only on the new structure and TCoEs’ rumored benefits, without assessing the capacity of the present structure to sustain re-factoring. It is sheer madness to attempt centralization across multiple product teams if even one of those teams’ methodologies relies on tribal knowledge, or if its processes rely on named individuals rather than abstract functional models. Nor does it make any sense to move product groups into a TCoE without standardizing basic tools such as defect databases and test case repositories. Knowing what to look for is where providers of TCoE services, like Mindtree, distinguish themselves.

For these reasons – the need for preparation — it’s better to move product or IT testing into TCoEs one unit at a time, not en masse. Preliminary assessment identifies which will be the easiest to move. While that’s happening, other groups can begin preparing for transition. Establish the structure of the TCoE first, then transition projects that require the least restructuring or new documentation for support by the TCoE.

Planning is essential. Knowledge transition, organizational structure, test planning, change management, governance, and scheduling should be exhaustively documented in the TCoE implementation plan.

One of the best but least exercised operations in TCoE planning is saying “No”. Some testing simply should not be moved into a TCoE. Agile methods can be adapted for TCoEs in a distributed model for projects less than a certain size (1500 function points may be the limit). Even pair programming, using inexpensive video conferencing tools like Skype, can be sustained in a TCoE model. Be very careful though when considering a company’s legacy green-screen customer database that is only understood by the two people who have been testing and debugging it for 30 years – “No” may be the very best strategy.

The eventual benefits of a TCoE can be game changing. But even before thinking about structuring TCoE governance, delivery, staffing, on-boarding, change management etc., take a level-headed look at your company’s development and QA organizations and ask if they can withstand the stress and dislocation that will accompany transitioning software testing to a TCoE.

In the simplest representation of what happens when a company transitions to a TCoE, one link in its chain of production is broken, and replaced by a new system of links having several new properties. The strength of the new system of links – the TCoE should be regarded as defining the strength of the entire chain. It had better be at least as strong as the link it replaced.

Obviously this is very serious stuff – at least as critical as a major change in QA leadership. Transition to a TCoE should be thoroughly thought out prior to implementation, with detailed planning based on impact and risk assessment, application profiling, and assessment of transition readiness.

Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.

  • Mahesh

    Hi John,

    The idea of TCoE looks good. However when Testing Group is treated as a separate entity (under TCoE) it may become too formal to communicate with our own teams (like development/marketing/QA). Information exchange/gathering may become too formal and may feel like as if we are directly interacting with Customers. This may affect the quantity and quality of the information available for testing.


  • Sumanth

    TSoE is a good idea to streamline things for testing dept. but with the testing team supporting multiple teams/projects without being recognized as a independent revenue earning entity, will it get its worth without being dependent on others.

  • Not sure what you’re saying, so please re-submit your reply if I’ve missed it. Testing should always be a separate entity – otherwise its judgement will be compromised, and its worth questioned. Internal communications, such as with the development team or with the PMO, are best kept formal so that there is no chance of misunderstanding. That’s obviously not the case if you’re working in Agile and the guy sits on the other side of the lab bench from you – you can talk through the issue. But you’ve mentioned “as if we are directly interacting with customers” – sounds like you are referencing a specific situation where members of a TCoE are not encouraged to interact directly with customers. I find that after about 6 weeks, you not only can but should encourage direct interaction, unless language differences (say Czech vs. Tamil) are too severe to overcome. Putting layers into communication only increases the possiblity of error, unless everything is formally structured, and then you have to worry that people won’t communicate because it takes too long.

  • That’s all about the engagement model and how the TCoE vendor structures its output-based incentive pay. If everyone in the TCoE has the same targets, you promote teamwork. If the test automation architect in the TCoE has a separate target, she’ll be inclined to tilt the work schedule to allow her to buy that new Miata, while the guys in security are still balancing on their Velos.