Testing Center of Excellence Clarified
Testing Center of Excellence is mostly a joke in reality
According to Software Testing Help, A Testing Center of Excellence (TCoE) is a framework that defines, implements & measures testing controls and standards across an organization. This article will clarify is this phoney term, in particular, from the perspective of test automation.
Some might say “our TCoE is more about manual testing”. Really? Let me list some terms that you might use multiple times a day:
Agile (or Scrum, or Kanban)
Release Early; Release Often
The foundation of all the above is “Test Automation”. If 80% of a TCoE’s work is not about Test Automation, it is rubbish.
Table of Contents:
· Putting ‘Excellent’ in a name does not mean Excellent at all
· Why do some CXOs believe in TCoE?
· Dissect TCoE
∘ 1. Central Testing Team is generally a bad practice
∘ 2. Standards (across the organization)Putting ‘Excellent’ in a name does not mean Excellent at all
Any adult would know that a person who always brags about his/her honesty or integrity, most likely, is the opposite. As an engineer, I don’t like the term “Testing Center of Excellence”. In some countries, you cannot register a company/product name with a fancy adjective + noun in a phrase structure, like these two: “Best Automation Tool” and “Highest-Winning-Ratio Lawyer”.
In reality, TCoE is a recipe for failure. It becomes a wonderland for talkers to appear busy in many rounds of useless meetings. If it is just pure time-wasting (and money), it is not too bad. Sadly, these people often introduce a process to make matters worse.
In this article (real story), An IT Graduate’s frustration with a Fake ‘Senior Test Automation Engineer’ sabotaged a uni-graduate intern’s effort to set up a CT server to do real test automation. The fake senior engineer (also the TcOE lead) tried and failed to develop/maintain ~20 automated tests. He was scared that if the intern’s CT server was running, the team members would see the benefits of test automation, and use it every day. The excuse the fearful fake senior automation tester used: “Our TCoE does not allow that”.
Why do some CXOs believe in TCoE?
The target of selling TCoE is to IT executives. Quality becoming a growing-important aspect of software development and maintenance. CXOs desire “Release Early; Release Often” badly, they think setting up a governing committee would help standardize the process and measure the testing maturity. Wrong!
Software Testing, especially Test Automation, is practical and target-oriented. More meetings and processes won’t help. That’s why I always follow the 35-Word Functional Test Automation Strategy.
Write 1+ Automated End-to-End Test for a user story;
Add it to the regression suite;
Run the regression suite daily and keep them valid!
Starting on the first day and then every day!
Dissect TCoE
In my opinion, taking out meaningless stuff, the core of TCoE are
Central testing service
Standards (across the organization)
1. Central Testing Team is generally a bad practice
In TCoE, by general understanding, testing is maintained as a centralized service and shared across the organization. It is an old concept, had been used decades ago (commonly in Waterfall).
I can silence this view via two hot testing terms:
Putting aside the specifics, the trend is quite clear: Testing Early, within the team! Facebook releases twice a day (I did the same for some client projects I led and all my own projects), and a central testing service definitely wouldn’t work.
2. Standards (across the organization)
No one can question setting up a standard practice in a company. However, the standards (especially in the context of testing) shall work by objective measurements. Now, the question, Is your test automation actually successful? Or Has it ever been once? The reality is, over my 12 years of test automation consulting in my city (and a few overseas ones remotely), every single company (small or large) failed test automation (against the Definition of End-to-End Test Automation Success). In fact, they didn’t even know what test automation could help the team from the first day and every day onwards, before I showed them. (see my daughter’s article Set up, Develop Automated UI tests and Run them in a CT server on your First day at work)
So, for the most so-called ‘Agile’ software projects which still heavily rely on manual testing, what’s the value of setting up more standards? Check out this article, Definition of End-to-End Test Automation Success.
Given the reality of so-many failed test automation attempts and many fake automated testers are pretending, the existence of TCoE often turned out to be a blocker. The current people in charge of TCoE would be more likely to sabotage (rather than help) any new promising hopes of real test automation.
In this article (real story), An IT Graduate’s frustration with a Fake ‘Senior Test Automation Engineer’. B is the TCoE lead. Selenium and Playwright are two approved automation frameworks in that large tech company.
After knowing a graduate intern did a few real automation tests in raw Selenium on the first day; B wanted the intern to use Playwright instead. (please note, Selenium is an approved framework there)
The intern asked B to demonstrate his Playwright tests. B eventually did, most of the ~20 tests failed. Also, there was no evidence of test execution history.
The intern implemented 26 automated tests in both Selenium and Playwright, and ran them daily in the local BuildWise CT server on the intern’s local machine.
The intern’s team leader wanted to keep using the test automaton after the intern’s leave. So the team requested a setup of a central BuildWise CT Server (just for the team use).
B rejected the team’s request for one Azure VM to run automated tests daily, based on TCoE ….
See, that’s what TCoE can be used by an incompetent person in fear.
From a different perspective, Selenium WebDriver, as a W3C standard, shall be proven in any TCoE since 2011. There shall not be any objections, right? Did you see any TCoE actually implemented real test automation using Selenium? Facebook could, LinkedIn could, I could, my 21-year-old daughter could, …, etc. The main success factor of Test automation & Continuous Testing is competence, certainly not about meetings.
The common case is TCoE spending a huge amount of time toggling different automation frameworks and tools.
FAQ
I was given a job to set up a TCoE, what shall I do then?
Start working hands-on on your company’s main project. You can only get the real working stuff (framework/tool/process) from the real work.
Check out this article, Test Automation and Continuous Testing Competition Week
Continuous Testing means the whole suite of automated tests would be run multiple times a day. So, a lengthy process certainly won’t work.
2. I want to include test automation in TCoE, but my test automation skills are sketchy. At the same time, I really want to move my career in that direction, any suggestions?
Don’t feel embarrassed, your lacking test automation is the failure of IT education and training in general. In fact, your admittance of lacking test automation skills is admirable.
My suggestion is simple: Learn it. By having the right mindset and hands-on attitude, you will be surprised how quickly you can make progress if on the correct track.
Check out this article: Advice on Self-Learning Test Automation with Selenium WebDriver and my new Selenium Workshop series.
Related reading