Test Center of Excellence: A Practical Implementation

Rajini Padmanaban
Test Center of Excellence (TCoE) is a term that is gaining a lot of visibility in the recent years due to the benefits of this execution model that have been widely talked about. When carefully planned for and diligently implemented, this model certainly has a lot to offer to improve the overall test team's productivity and efficiency. This write-up aims at talking about things to keep in mind in such a TCoE implementation to make the overall adoption process smooth and successful.

Firstly, let's look at what a TCoE is. A TCoE is a team model where multiple teams come together to work in a 'shared' mode to share knowledge, best practices and resources. It is a model that retains the core specialization of individual teams, yet offers room for cross-team collaboration.

The ideal operating model to be implemented for a TCoE will be one that leverages the strengths of the TCoE setup and at the same time does not add too much overhead and bureaucracy to the overall setup. It will be setup as a model that promotes end-to-end collaboration, yielding:

  • Team load balancing
  • Cross product knowledge
  • Tools and process sharing
  • Faster team ramp up
  • Access to specialists

Individual silos with core teams will be set up for specific projects so as to have focused test efforts to meet the quality needs of each of the projects. These individual teams will be managed by lead-level resources who will manage daily project deliverables. Virtual teams will be set up with specialists to handle specialized testing needs such as performance, security, globalization, accessibility/usability across the TCoE projects. Given that these testing needs do not span throughout the Software Testing Life Cycle (STLC) and these resources are expensive, they will work as a virtual team to address the specialized testing needs of all the projects in the TCoE umbrella, rather than just one project. All these leads, their respective teams and the virtual specialized teams will report to a test manager, who will manage the overarching TCoE. He/She will ensure:

  • Projects share common best practices.
  • Teams understand the bigger picture and quality requirements at large so as to drive value upstream.
  • Teams are empowered with the required common training.
  • Buffer resources are maintained across projects to take care of flexible and dynamic project needs.

Such a test manager will work closely with the stakeholders from the product team and conduct quarterly reviews reflecting the work done under the TCoE umbrella helping everyone on the product team understand and be on the same page about the project and product status and health, from a QA standpoint. This review will not be just a retrospective/backward-looking meeting, but will be proactive in focusing on the road ahead to practically implement an objective QA effort. A visual representation of this model is seen below:

The test manager should encourage monthly meetings of the entire team, inclusive of all projects in the TCoE umbrella. During such meetings, the following could be discussed: project accomplishments, challenges, workarounds, presentations made by team members on specific products/new technologies. Such monthly meetings could also set aside 15 to 30 minutes for cross-group bug bashes, allowing testers from other teams to test cross-group products. This promotes cross-product knowledge as well as helps to find bugs that the core team may have missed. Such meetings bring in good team bonding, which plays a major role in the TCoE's success. Email aliases should be set up for intra-project and inter-project communication, helping to share useful information to the required set of people on time.

Dedicated training should be conducted periodically either during monthly team meetings or outside of such sessions. Depending on the size and scale of the TCoE implementation, the test manager should determine the size of the buffer team to be maintained. Such a team will be trained and ready to work on any of the TCoE projects within a very short lead time. Typically, a 10 percent shadow/buffer team of the overall team size is a good size to have providing the flexibility of the shadow team, while not being an expensive overhead to maintain.

Thus, a TCoE has its own nuances for a right implementation. A test manager plays a very pivotal role in its successful implementation. As a first step, the test manager should get buy-in from the overall product team in educating them about the model, how it works, etc. and then carefully implement the TCoE as a step-by-step process. Such a planned approach, along with the test manager's objective mindset open to feedback, will help make the overall model a success and well received by the entire product team.


We, at QA InfoTech, have successfully leveraged the TCoE model for some of our strategic project implementations, including one for a leading ISV in the rich media product space. Our team strength for this account at peak times has been upwards of 75 people. This included testers onsite at the client's location, and on our premises, each working on different release cycles, reporting into various client managers. From our end, we had an overarching TCoE setup that accommodated the individual needs of each project, but provided specialists across the board. Our common pool of buffers, combined with different release cycles at the client's end, helped us effectively load balance resources. Such cross sharing of resources also helped share knowledge across projects, build detailed product and process training material and also helped the entire team understand the overall mission of the test effort. Such a team setup not only helped provide great opportunities to our team, but also shared the economies of scale with the client in providing cost-effective services at a much faster turnaround.

 



Add Comment      Leave a comment on this blog post
Oct 5, 2011 5:10 PM Jay Jay  says:
Thank you for the clear-headed critic. My friend and I were preparing to do some study about that. We got a great book on that matter from our local library and numerous books are not as cognitive as your blog. I am exited to see such information that I have been searching for a long time. :) Reply
Oct 10, 2011 7:10 PM Rajini P Rajini P  says:
Thanks Jay. Glad this was useful to you. Reply
Oct 18, 2011 8:10 AM Sankar Santhanaraman Sankar Santhanaraman  says:
While I agree with Rajni�s views on today�s TCoEs being primarily an operating and governance model, I strongly believe that this version of the TCoE has reached its shelf-life and it�s time for organizations to start looking at a more futuristic model of TCoEs. Today�s organizations need TCoE models that can help them forecast and meet future business needs, while still delivering on the current needs like optimized costs, faster time to market, lower TCO and achieve much more. Over the years of my work, I have discerned that organizations are trying all possible ways to reduce their IT spends and move from a CAPEX to an OPEX model. Hence, the next generation of the TCoE model according to me would need to focus on three primary dimensions (a) Testing Services (b) Testing Tools and (c) Testing Infrastructure. To know more about the same please visit us at www.infosysblogs.com/testing-services Reply
Oct 25, 2011 8:04 PM Rajini P Rajini P  says: in response to Sankar Santhanaraman
Sankar - thanks for taking the time to read and post your comment. You are right about the focus areas you have listed above.IMHO, these are add on dimensions to the base / core model explained above. Focusing on these is not going to change the model's incarnation itself and infact such a model is going to better empower to embrace these focus areas such as services, tools, infrastructure. Infact there are other important dimensions to also consider esp. when we talk about services such as SLAs, which are more effective when a shared team model (like the one explained here) is in effect. Hope this clarifies. Reply
Oct 25, 2011 8:10 PM  says:
Sankar - thanks for taking the time to read and post your comment. You are right about the focus areas you have listed above.IMHO, these are add on dimensions to the base / core model explained above. Focusing on these is not going to change the model's incarnation itself and infact such a model is going to better empower to embrace these focus areas such as services, tools, infrastructure. Infact there are other important dimensions to also consider esp. when we talk about services such as SLAs, which are more effective when a shared team model (like the one explained here) is in effect. Hope this clarifies. Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 
Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data