View recording of webinar:
Create your Testing Center of Excellence (CoE)
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