An insight into the Testing Center of Excellence
Testing Centers of Excellence (TCoEs), which are aimed at consolidating QA resources dispersed around the enterprise’s units, have become an issue of ambivalent feelings for numerous organizations. On the one hand, TCoE is a way to benefits brought by centralized QA resources, unified testing quality standards and more. On the other, it is related to a number of drawbacks, one of them being significant organizational efforts for its setup and evolution.
Let’s try to see the forest for the trees and outline what idea lies in the core of TCoE, what pitfalls to be aware of, what real benefits it can bring and how to create a successful TCoE.
TCoEs are most appropriate for large-scale enterprises with a complicated organizational structure comprising a number of departments, subdivisions and lines of business (LoBs). Such big enterprises have several QA engineers assigned to each LoB. Quite often, these companies face such challenges as relevant QA budgets and employees allocation, the need to standardize testing quality requirements and documentation. And this is where TCoE may come to be of help.
TCoE comprises 3 major components: QA processes it has to cope with (QA promotion, QA requirements, testing resources and testing process management, the control over testing efficiency and more); human resources it comprises (manual test engineers, test automation engineers, QA and test managers); tools that are used (bug and issue tracking tools, test automation frameworks). TCoE consolidates these main components and standardizes their elements to perform and manage QA and software testing required by all the LoBs.
Being a particular case of centralization within an enterprise, TCoE is bound to natural problems of any centralization.
Each fully centralized structure is prone to bureaucracy. The decision-making function in QA and testing processes and their management may be constricted to TCoE managers while leaving project managers and test engineers without an opportunity to contribute. This may lead to their lack of initiative and QA strategy misunderstanding.
Another problematic issue of a fully centralized TCoE is constrained cooperation among different teams, particularly, in DevOps/Continuous Delivery and Agile projects. TCoE needs to meet a project team’s needs, and at the same time, project stakeholders are to meet high QA standards imposed by TCoE. Reluctance to be subject to the demands of a different organization’s unit may result in unreasonable testing or testing gaps in code changes. Besides, when all test engineers are seated apart from developers, quick testing response to code amendments is complicated.
Now, let’s consider TCoE practical benefits to see whether they outbalance the highlighted challenges:
Relevant test automation
Test automation can shorten testing time, improve testing quality and provide coverage unachievable with manual testing efforts. Still, you need to mind that not all test cases are appropriate for automation. There’s no point in scripting test cases that are unique for each software release or source code modification and the ones that are rarely repeated. TCoE team collects and categorizes all manual test cases. Thus, it’s much easier to decide which test scenarios are to be automated and which ones not. Besides, TCoE is responsible for the unification of test automation tools, accumulation of reusable automated test cases and scenarios, deciding on the right time for test automation and its relevancy for a specific project.
Enhanced manual testing
Gathering test processes and artifacts, analyzing them and developing a unified testing methodology improve the quality of manual testing. Test engineers use a proven coherent testing methodology and testing standards provided by TCoE, which is aimed at facilitating the testing process itself, as well as bug reports creation. It is reported that with TCoE the rate of missed severe bugs, one the most tangible marker of testing quality, can be minimized to 2%.
Balanced testing resources allocation
In the absence of TCoE, project managers trying to stick to the budget may economize on QA and assign insufficient testing human resources. TCoEs can be efficient in QA resources balancing. TCoE managers can suggest test teams of balanced scale and competency to meet testing budget limits. In case it may be achieved only through compromising on testing quality, they may advise a project manager to extend the budget accordingly, not to result in greater financial loses due to the release of the bugged software. As for balancing testing human resources: in case of test engineers’ low workload within their project, they are easily shifted to facilitate testing of the more demanding one.
If a project requires additional or specific testing resources, you may turn to QA outsourcing to scale up a testing team and acquire best-of-breed professionals. Still, it may be not so easy to start testing outsourcing from scratch. To get cracking with QA outsourcing, you need to consolidate workflows, gather multilevel software requirements, and overcome developers’ reluctance to cooperate with outsourced testers. And TCoE may help with that. QA processes established by TCoE cater for smooth workflows. TCoE’s general QA standards and templates can help BAs prepare consistent software requirements and articulate them in the way coherent for the testing team. At the higher levels of TCoE maturity, when TCoE becomes a separate fully functioning unit, there is no critical difference for the developers whether to cooperate with in-house or outsourced test engineers. This way, they are ready to use conventional communication channels and procedures to cooperate with an outsourced test team. In addition, the sufficient QA staff needed to manage either single or multiple QA outsourcing vendors is available within your TCoE and can step in when needed.
Higher QA maturity level
TCoE can be a way to higher QA maturity levels, which presuppose that testing resources and processes are optimized, developers ensure code readability and testability, testing process is constantly analyzed on the basis of ‘input-output’ ratio, new testing methodologies and tools are continuously considered and introduced. Besides, it’s easier to establish one common QA process, advance it through its maturity stages and promote around the enterprise than to develop a number of them for each LoB.
TCoE creation requires significant organizational efforts and costs. Either your in-house QA team may go into TCoE creation and nurture, or you can turn to professional outsourcing teams to learn the ropes of your existing QA processes and standards, perform QA maturity assessment, provide a tailor-made TCoE creation plan and help you with its execution.
To make TCoE’s setup less problematic, you can start from a small-scale ‘virtual’ TCoE. It implies that the dedicated employees don’t change their location but become a part of a new ‘virtual’ organizational entity with its own structure and specific workflows.
Usually, a TCoE setup and evolution process comprises the following steps.
Step 1. Accumulation of methodologies, metrics, standards, and policies. At this stage, fundamental testing quality standards, policies, basic reporting procedures, and best practices are consolidated.
Step 2. Knowledge transfer. You need to employ or provide training to the existing QA and test managers, manual test engineers, and test automation engineers for them to get universally high qualifications to handle relevant testing or managerial duties.
Step 3. TCoE’s stabilization. Starting from this stage, you may already say that a set up period is over and you have a TCoE. The team standardizes QA and testing methodologies, process and tools. They perform and manage their first testing projects.
Step 4. TCoE’s steady development. At this level, TCoE is in the middle of its maturity. It acts as a central source of QA services for the organization. QA professionals evaluate and adjust QA processes in the enterprise to make them more efficient. TCoE team provides QA consultancy and aid for all the departments, handles the majority of software testing projects of the enterprise, proposes appropriate testing resources in accordance with business requirements.
Step 5. TCoE’s strive for continuous innovation. Now, TCoE provides testing services, methodology, tools and expertise, advice balanced testing resources, and manage all testing projects. TCoE members constantly measure each testing project’s results, develop new quality practices, create and adapt new testing tools and frameworks.
TCoE has more chances to succeed, if not only the executives but the whole enterprise acknowledge and support the idea of its construction and future collaboration with it. The full TCoE evolution process with sufficient executive support requires about 24 months. Still, the good news is that you don’t need to go through all the steps at one go. You can easily stop after each step and proceed only when your TCoE KPIs demonstrate tangible QA improvements. In this way, you can scale up TCoE at your own pace.
TCoE basics that are not to be missed while setting it up
Deep business understanding
All the activities of your future TCoE should aim at the promotion of the enterprise’s business priorities. The general QA strategy and policies are developed within TCoE, and then are constantly shared and advanced through all the LoBs. It is also crucial for your future TCoE to provide effective testing strategies and assist with the adequate testing resources allocation for each project in accordance with business priorities.
Profound software knowledge
QA experts assigned to a certain LoB know their relevant software deeply and are aware of possible development and testing complications due to, for example, legacy solutions. TCoE is to comprise the software competency of highly specialized QA professionals and the benefits brought by unified QA standards. It can be achieved with the help of knowledge transfer, testing management and transparent testing quality evaluation.
Alignment of project teams and TCoE
Project teams need to constantly and eagerly collaborate with TCoE team members and vice versa. Conventional cooperation procedures and communication channels should be established from the TCoE stabilization level to ensure the smooth collaboration process.
On a final note
TCoE’s main aim is to centralize fragmented QA resources assigned to each LoB. This centralization may result in a number of concerns. Still, keeping in mind that TCoE should cater to business priorities, deep software understanding, and constant communication between TCoE staff and project teams, TCoE can help you reach some practical QA goals. It can be a way to wisely managed software testing resources, enhanced testing performance, appropriate test automation and higher QA maturity levels.