From Testing Center of Excellence to Testing Center of Practice

testing center of excellence

Determining the average development process across an engineering organization is a challenge. The mobile team might do constant pairing and continuous integration, while the infrastructure team team is on a 6 month release cycle with distinct handoffs between developers and testers, and the front end team is doing something more like agile-fall or iterative development. Companies with thousands of employees have divisions within divisions, and each team does things just a little bit differently.  This segmentation of development types can cause headaches for large development teams in coordination, visibility, and communication
Despite the differences in these product teams, teams usually have something to offer each other in terms of skill development and best practices. How can these teams share the good parts and make steps forward while being maintaining their independence?

Testing Center of Excellence

The growing trend for enterprises looking to centralize development best practices is a Center of Excellence (CoE). In a typical CoE, one representative from each team attends a meeting once a month. In that meeting the group talks about new practices, problems that are common across the organization, and a few possible solutions. When the meeting ends, people go back to their teams and share what they learned. The CoE is an effort to standardize best practices and train a small group of people that will go off and communicate that to everyone else. Many times, these systems don’t quite work out, and the center struggles to show ROI to justify the additional overhead.

Testing Center of Practice

Many organizations are making a shift from Centers of Excellence to a Center of Practice (CoP). Think about a software company that has three different product modules, each built on top of a shared REST API. One group has built an automation framework to integrate to the API, but the other two groups are yet to automate their API tests and are still running them manually. When the three modules must coordinate on a major product release, this lack of automation can causes everyone’s releases to run behind. This is a prime opportunity to share experiences and skills to create one set of best practices.

Given a meeting room and a little time, the team with some experience could do a few things — they could demo what they have built so far by running some code and explaining what it does, they could talk about what they like (or don’t) about the tools they are using, or even pair up with non-technical testers to help the other teams build their first API tests. The other teams listen, ask questions, start building their own tests, and ask for review or help. These collaborative interactions help everyone to be better at what they do.

After that session, the testers go back to their projects for a little bit to work on their own API tests and get some experience. Instead of putting responsibility of sharing new information on a small group of people, the CoP invites anyone that wants to participate. Ultimately, everyone there gets valuable experiences that enhances their knowledge and skills; the demonstrators learn more about what they are building from explaining the work, and everyone else dips their toes in a new skill set.

Once a week, or once a month, the frequency isn’t mandated as long as it provides frequent enough touch points without causing unnecessary friction or overhead. But, make a space available to anyone that wants to be there for an hour, during a time that is typically open (i.e. not conflicting with stand ups or lunch) That only sends the message that improvement is something the company values when they don’t have to deal with it. During that hour practice session, the people that show up set the agenda. That might be to talk about one team that is trying test driven development, or another that is spending some time with developer / tester pairing, or another team that has recently started doing API automation.

Companies like to standardize on tools and process because costs go down when variation is rooted out. In a large organization, one team is using kanban boards, another uses scrum, and all are using different bug tracking or enterprise test management systems. CoPs help people discover this variation by sharing what is really happening, not what is in the company process document. Eventually, there are fewer products to support, less time to figure out what a team is doing, and it is easier for people to move around in the organization.

Skill development is a long term effort, ideally it never ends. There are plenty of ways to get it done. Some companies offer support for training classes, books, and conferences. Others place the onus on the employee. Creating center of practice, a place where people can share and learn on company time, is a good place to start. Go forth and learn.
Learn best practices for making the agile transformation with your people, process and tools in this on-demand webinar, “Agile Transformation: People, Process and Tools to Make Your Transformation Successful”.

Leave a Reply

Your email address will not be published. Required fields are marked *

More Great Content

Get Started with QASymphony