Testing Centers of Excellence and the Return of Silos
I've seen job postings for testing centers of excellence (CoEs) and dreamed of working in such a place. I imagined that these organizations would bring the best software testing and QA professionals together and explore the most effective ways to test their various applications.
The CoE would be an R&D lab for software testing, experimenting, and innovating new testing techniques and then piloting them on projects, collecting data, analyzing the results, and adopting or recommending the techniques for future projects.
The CoE also could offer more down-to-earth services, like being consultants to groups using or wanting to use test automation, collecting metrics, and performing root cause analysis. Staff could be made available to help business people write user acceptance tests instead of having testers do it. The CoE could explore ways to reduce waste, especially in the area of documentation. And if the company outsources development or testing, the CoE could provide test data models to their vendors showing the kinds of scenarios that should be included in their testing.
I recently learned the details of a company that established a testing CoE and realized the reality.
What changed? The company’s old way of working was to have cross-functional teams, similar to agile teams, where a mix of people were collocated for ease of communication. The testing CoE disbanded this practice, and testing became a separate group, with all testers located together away from the developers, project managers, and database administrators. Even worse, testers were instructed not to interact with developers, and vice versa. Project managers embraced this new environment because they saw testers as distracting their developers, delaying code delivery.
In effect, the silos returned. Instead of advancing testing, the CoE made it take a step backward.
The goal of this testing CoE is to make testers interchangeable. They would like every tester to be able to fill in for any other tester. This might work if you have a small number of very simple applications, but it will never work for what this company is doing, which is testing large, complex applications across many different industries for their various clients.
The one positive aspect is that management encouraged testers to get domain knowledge and certifications in different industries. The company didn't give study time or pay for obtaining these certifications, but they were happy that some testers took their own initiative to do so.
So, to summarize, did the testing CoE introduce new testing techniques? No. Did it improve testing effectiveness? No. Did it change day-to-day testing activities? Yes—in that testers were isolated.
Where is the excellence?
Maybe it's too soon, or perhaps they have plans to improve on quality (although I would have had these plans in place before establishing a testing CoE). But by isolating testers from developers, administrators, and analysts, any improvement in software quality will be greatly limited by being so far downstream.
What's your experience with testing CoEs? Have you seen an emphasis on software quality, or was it on speed or economics?
