Centers of Excellence (CoE) are not new in our Software Development and Testing ecosystems, but for some reason we do not see them often enough in testing and specifically in Test Management.
This session discusses the concept, importance and creation of a test management Center of Excellence.
What exactly characterizes the Center of Excellence?
From both a high-level perspective and a low-level perspective, what identifies the Center of Excellence is a small group of people that have very deep knowledge and experience on a specific topic. The people in the CoE will usually be from different groups in the organization and the logic behind this is that they can bring their points of view from different teams. What they are doing as a group is sharing, researching, defining, and even spreading information about specific topic expertise.
In addition to this definition, here are the key points for establishing a Center of Excellence:
Authority – It will be more efficient to have executive sponsorship in the sense that not only will it be more legitimate, you also might be able to get some time allocation of some resources.
Participation – It should be both voluntary and selective. You want the people who are part of that Center of Excellence to be experts so only bring those with expertise that is above average.
Objective – The objective of the center is to research, develop, and share our resources, but, it needs to have concrete deliverables.
Deliverables – Deliverables meaning can be a whole range of things from practices, tools, frameworks, KPIs, training guides, etc.
Examples of where we can implement Center of Excellence
Test Management
Test Automation
Security Testing
Performance Testing
Compliance Testing
Cross-Platform Testing
Localization Testing
Testing in Production
Misconceptions about implementing a Center of Excellence
There are two main misconceptions:
The first one is when people say “we don’t want to work with the center of excellence because we don’t want to have someone from outside the team dictate to us how we should work”. This is a misconception because the approach we will be using depends on our constraints and the product, and not from the Center of Excellence. The CoE shares information and practices but those are only suggestions and not going to be dictated on the teams. The only place it might happen is if your management wants to have a unified process, but then it is the management that dictates the team.
The second point is when some people say that they don’t like working with the Center of Excellence because they will limit the innovation of the teams, mistakenly thinking that all of that innovation will be diverted to the CoE. The truth is that people working in the CoE don’t have time because they are working their daily job so when they sit in the CoE it’s more about sharing what they are doing in their day-to-day lives, about the challenges or tools they have. The innovations still will come from the teams because they will have the need, the resources, and obviously the motivation to do that.
Test Management Center of Excellence – Why?
Multiple teams working each with their own process
Low reusability of artifacts, resources, and testers
Hard to generate integrated reports/dashboards
High costs of onboarding new teams
Low levels of innovation around test management in the organization
Test Management Center of Excellence – How?
Get managerial sponsorship
Select experienced & knowledgeable people from each team
Set up a workgroup – don’t make much noise at the start
Understand the challenges of each team
Set up an initial set of goals – get approval from management on these goals
Test Management Center of Excellence – Real-life example
The company in this example is a fortune 500 insurance company. Working on the Center of Excellence approach with this company started because PractiTest was selected as the tool to be implemented and deployed on these 3 teams.
Profile of the test teams
3 Business units with 3, 4, and 6 different products
4 sites in different countries in Europe & 2 outsourcing in different countries
Around 80 Testers & Managers
2 Agile working teams & 1 team transitioning from Waterfall to Agile
Each team has different automation tools
Products are independent but with strong integrations among them
Step 1 – PractiTest Implementation
Mapping the main needs and processes of the teams.
Select the teams deployment order: 1 > 2 > All
Defining the minimal standard process (a primary path shared by every team):
Reports and Graphs reported to the management
Field customization (minimal standard fields)
Permissions and groups (SSO integration)
Migration of existing data from different data sources (Import > Fine-tuning > Import)
Setting up the integration with Jira
The Center of Excellence included one representative from each team and Joel, making it a total of 4 people. The deliverables of this phase were a couple of demo projects with the Jira integration set up so people could try it, and the minimal standard process so one representative from each group could go and present it to their teams.
Step 2 – Training and Onboarding
Internal training approach:
Project Managers by PractiTest
Team Leads by Center of Excellence
Testers by Center of Excellence & PactiTest’s Certification 1 month later
Individual work with each team to migrate and onboard them into the system:
Data migration
Additional specific fields
Initial filters & Dashboards
Step 3 – Testing Best Practices
Testing guidelines
Scripted testing types (checklist vs. low level)
Session-Based Exploratory Testing (exiting in one team, then expanding to the other two teams)
Jira integration guidelines:
Importing user stories
Reporting defects
Embedding graphs in Confluence Dashboards
Field synchronization
Step 4 – Internal Support & Knowledge Base
Setup internal Knowledge Base pages
Created an email for internal PractiTest Q&A
Step 5 – Management Dashboards
Definition of relevant KPIs and Dashboards
Gap analysis for information to be captured
Definition of a standard set of graphs
Creation of a unified view in Confluence
Step 6 – Automation Integration
Mapping of internal tools & frameworks, selection of those to integrate
Work with their Automation team on POC around PractiTest API
Modifications to their projects to accommodate Automation reporting
Implementation and fine-tuning
Strong additional “Win’s” from the Center of Excellence
More control over the process and the system
Faster turnaround time on questions and issues, both internally and with PractiTest’s Customer Success Team
More collaboration between the teams, Sharing of ideas and practices around processes and practices
Shared resources (around test automation and integration)
Higher recognition from management on the deliverables of the QA (Dashboards & Reports)
Expansion of “testing” to include unit & integration tests running on Jenkins
We use cookies to make this site work better for you. Accept, or adjust your preferences.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.