Thinking about Testing Centers of Excellence

Posted by MindTree Blog Archives in

 Testing

Apr 27, 2010 | Total views: 108

4

MindTree Blog Archives

More articles by the author

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.