Is Building a Testing Centre of Excellence Worth It?

In my last post, Building a Testing Centre of Excellence, I identified the first few steps needed to create a testing centre of excellence. These are:

• Build the business case.
• Define and share your vision.
• Create the leadership team.
• Define your operating and financial model.

Now that it’s so critical to success, I’ll just reiterate one thing, the TCOE must have control of its own budget and should not be funded entirely by projects.

I’d now like to build upon the previous posts and give a practical approach to defining the scope of services the TCOE should deliver. Like everything in life, it’s not “one size fits all” and the scope should fulfil the business and IT needs. Usually, there will be some obvious organisational issues that need addressing. Often these include, but are not limited to, inconsistencies of testing practices between business units or teams, lack of maturity, lack of skills, inefficiencies, tooling issues or a combination of the above.

Defining the Scope of Services

The starting point should be to identify what’s broken, what’s missing, what could be better and importantly, what’s working well. These things don’t just apply to testing in isolation - the touch points with testing also need to be explored. For example, the business interaction for requirements, the SDLC, the SCRUM process, the budget allocation and the demand management process should be examined.

To do this you’ll need to solicit frank and honest feedback on testing and its dependencies from various stakeholders within the organisation. There will be different views and biases so it’s important to take a neutral stance in order to navigate this potential minefield and identify the patterns. It’s also important to try not to solutionise before all the information is gathered, sifted and understood.

Listening to the various stakeholders and getting their opinion of where the problems are, what’s not working and what is, can be a very cathartic experience for them. It’s a chance for them to air their grievance and frustrations. Typically, I find trends and patterns emerge quickly and the solution creates itself, but you need to know what questions to ask so that you can lead the interviews and draw out the necessary information, recommendations and suggestions. You’ll need to create trust and use active listening skills to get the most out of the interviews. I strongly recommend reading Active Listening by Carl Rodgers and Richard E Farson for anyone performing this kind of role.

Who should you talk to?

The people I suggest you need to get feedback and opinion from include whoever is driving the change and whoever is impacted by the change. The list will likely include the following:

• Heads of IT
• Product owners and BAs
• PMO, Project Managers and SCRUM masters
• Business representatives
• SMEs, senior and junior members of the testing community
• Senior and junior members of the development community
• Operations and support team members (who need to deal with the fallout of quality issues)

The Interviews

You’ll need a comfortable place to meet (during this phase you’ll get through a lot of cups of tea, so be prepared). I space out my meetings so that I can prepare properly beforehand and write up my notes after each interview. I don’t take lots of detailed notes while talking to the interviewees as I find it gets in the way of effective communication (or I forget to write). I find it’s therefore important to write them up immediately after the interview so that they are as accurate as possible.

It’s virtually impossible to accurately document a meeting if it’s not done immediately – particularly if you conduct multiple meetings in a day over multiple days. Ideally, you’ll have a scribe supporting you. Even then it’s worth comparing notes and formalising them straight away. I advise that you conduct no more than three interviews in any one day. After each interview, you need to meditate on the findings and draw some conclusions. It’s also necessary to plan each interview and decide what you want to find out and what you need to corroborate and verify.

What documentation do you need to review?

In order to understand the current state of testing, you’ll need access to a range of documentation from the various areas of the organisation or business units that you want to centralise. This will enable you to compare and contrast, identify commonality and find the good, the bad and the ugly. The documents I usually review are:

• Test policy documents
• Overarching Test Strategy
• Example Test Plans
• Example Test Scripts
• Current Organisation Chart
• Test Metrics and KPIs (if they exist)
• Defect Management Process
• Tooling and Licence information
• Automation frameworks

In my next blog, I’ll give some examples of the scope of services from a 'Testing Centre of Excellence' and the final steps you’ll need to consider to successfully implement a Testing Centre of Excellence. Lastly, if you need any help on this subject reach out here and we can schedule some time to talk.