QA coaching as a central service means a small quality assurance team doesn’t do the testing itself. It advises projects, reviews test plans and maintains standards together with a community of practice. Rather than acting as a gatekeeper, the team works with projects as equals, provides templates and helps choose external service providers.
Key Takeaways
- With just eight people, the QA team at the IT system house of Germany’s Federal Employment Agency supports around 100 to 120 IT applications without placing its own testers in projects.
- Replacing a Word test manual several hundred pages long only worked once the team openly asked the projects about their pain points and let a community of practice grow out of that.
- Switching from a “test directive” to “test guardrails” was more than a new name: fewer binding rules, higher acceptance and voluntary test plan reviews replaced the old control function.
- Making reviews voluntary has a downside: some projects took the dropped requirement as an excuse and have skipped test plans entirely ever since.
QA Coaching Instead of Control: Why Acceptance Beats the Sign-Off
Central quality assurance works better as a coaching offer than as a control function. The IT system house of Germany’s Federal Employment Agency made that shift over roughly ten years. Today, a team of eight handles testing and quality assurance topics for about 100 to 120 IT applications without sending any of its own staff into the projects.
The decisive difference is the role. A team that hands out the release sign-off gets feared and worked around. A team that advises as an equal gets invited in. Christian Ulrich describes the effect plainly: with offers such as a quality-of-test check or test plan reviews, the team now has a much better connection to the projects.
How a 300-Page Test Manual Became Test Guardrails
The old test manual was a hefty Word tome, and nobody read it. Acceptance was as low as you would expect. The rebuild didn’t start with a new template. It started with a question to the people who had to live with the manual.
The team recruited volunteers from every part of the IT system house for a community of practice. At the first meeting, the question was: Where does this document hurt? Which of these rules can you not follow at all? The first reaction was suspicion. For years, the same unit had been checking up on them, and now it was asking about their pain points.
“For years they gave us a hard time, and now they come at us like this. That was really the icebreaker, when they noticed these people really mean it.”
(Christian Ulrich)
That sincere change of perspective was the turning point. The Word document turned into a leaner structure in Confluence. The strict “test directive” became “test guardrails,” which leave more room to maneuver and demand less detailed description.
What Has to Stay: Legal Requirements as a Hard Limit
Not everything could be slimmed down. As a public authority, the IT system house is bound by regulations and legal requirements that have to stay in the document. For years, that was the conflict: low acceptance on one side, non-negotiable obligations on the other.
The way out was separation. Whatever is mandatory is explained as such and stays. Everything else was opened up. There are fewer guardrails now, and they are still binding, but they have been agreed with the stakeholders. Because the rules are accepted, the team no longer needs to play the controller.
To keep the slimmed-down version from freezing in place, the team reviews the legal texts regularly. If something needs to change, it brings the community back together and looks at how the change affects the rest of the rules.
How Central QA Plugs into the Projects
The central unit has no say in project staffing, but it reaches out early. As soon as a project gets new staff, the team offers its services: a test plan template, help with testing questions, support in choosing external service providers.
That early involvement has a clear purpose. Testing and quality should be part of the project from day one, even though the small unit can’t assign its own people. When projects pick external service providers, the team asks targeted questions, and the answers often already show whether a provider fits the project.
Test execution stays with the teams. They are put together so that every discipline is represented, even though the aim is for everyone to work T-shaped. Testers are part of these teams and run the tests. Acceptance happens at the end of the sprint, often with representatives from the business side.
Load and performance testing is the exception. A separate central unit runs those tests, and teams can hand that work over to it.
Testing Quadrants Instead of Test Levels: Developer Tests Belong in the Plan
Moving from classic test levels to testing quadrants has brought developer tests visibly into the test plan. Whole chapters used to be spent on handling test levels. Today, the testing quadrants structure the plan.
That has a practical effect. Many developer tests sit in the first quadrant, so they show up in the test plan automatically. The plan is no longer a document only for downstream testing activities. It also reflects what developers contribute.
Behind this is the hope for synergies. When team members with a testing focus and those with a development focus share one strategy, quality can be secured earlier. The goal is shift left: test things as early as possible, because defects are cheaper and faster to fix at that point.
When Voluntary Becomes an Excuse
A voluntary review doesn’t replace a mandatory sign-off one for one. This is where the team misjudged things. As long as the review was mandatory, nobody got through a release without the sign-off. Once it became voluntary, some projects took that as an excuse and did their own thing.
The team is correcting course. Not every project is back on board, but more of them now see the need for at least minimal documentation of the test plan. Giving up control means you have to persuade people instead, and one round of persuasion is not enough.
The gap the team sees is in the exchange between disciplines. Too often, testing and development experts still don’t know enough about each other’s work. Attitudes like “I don’t do testing, that’s the tester’s job” or “unit tests are plenty” are hard to shake. The team still sees room to improve here.
What Other Organizations Can Take from This
Even a public-sector organization can practice agility and lean quality assurance. The IT system house shows that the biggest lever is not a better document but a different role and genuine involvement of the people affected.
If you are staring at a test manual nobody reads, the first useful question is not “How do we shorten this?” but “Where does it hurt the teams?” A community of practice turns the people affected into co-authors. Mandatory parts stay, with a reason attached; the rest becomes negotiable.
Moving from control to coaching doesn’t happen by itself. It takes trust, which has to be earned first, and it brings setbacks, for example when voluntary turns into an excuse. Sharing those experiences is possible, even beyond your own organization.
Frequently Asked Questions
Why does hardly anyone in organizations read the official test manual?
It’s often due to the format and how it was created. At the Federal Employment Agency’s IT system house, the old test manual ran to several hundred pages in Word, and nobody read it. Acceptance only increased when the QA team asked the projects where the guidelines were causing problems and what couldn’t be followed at all. This led to leaner test guidelines in Confluence.
Can a small, centralized QA team manage many applications without doing the testing themselves?
Yes. Eight people manage testing and quality assurance for about 100 to 120 IT applications without assigning their own staff to the projects. This is made possible by a range of services: templates for test plans, reviews, a quality-of-test check, and support in selecting external service providers. The test execution remains the responsibility of the teams.
How does a community of practice help in revising testing standards?
It turns those affected into active contributors. Volunteers from every department were recruited for the revision, and the first question asked at the meeting wasn’t “How can we shorten this?” but “Where does this document cause you problems?” The initial reaction was one of mistrust, because the same unit had been in charge of oversight for years. It was precisely this sincere shift in perspective that became the turning point.
How can legal obligations be reconciled with lean testing standards?
Through separation. What is mandatory due to regulations remains in the rulebook but is explicitly designated as mandatory. Everything else is open for discussion and coordinated with stakeholders. The remaining guidelines have been reduced in number but remain binding. To ensure that this streamlining doesn’t become stagnant, the team regularly reviews the legal texts and, if changes are needed, brings the community back together.
When should a central quality assurance team approach a new project?
As early as possible, practically speaking when the project team is being assembled. The QA team is not involved in staffing the project but offers its services immediately afterward: a template for the test plan, assistance with test questions, and support in selecting external service providers. The goal is to embed the concepts of testing and quality into the project, even without being able to assign dedicated personnel.
Who conducts the tests if the central unit only provides advice?
The teams themselves. They are composed so that every discipline is represented (including testers), while also requiring that everyone work in a T-shaped manner. Acceptance testing takes place at the end of the sprint, often with representatives from the business units. Load and performance tests are an exception: there is a separate central unit for these, to which a team can delegate the task.
How do you incorporate developer tests into a test plan?
One approach involves using testing quadrants instead of test levels. In the past, chapters on handling test levels filled the strategy; now, the quadrants structure it. Many development tests fall within the first quadrant and thus automatically appear in the test plan. The test plan no longer describes only downstream test activities and supports the goal of finding defects earlier and more cost-effectively.
Is it worth switching mandatory test plan reviews to a voluntary basis?
This move has a downside that was underestimated at the IT system house. As long as the review was mandatory, no project could be released without the sign-off. After the change, some projects used the voluntary nature of the reviews as an excuse and dispensed with test plans entirely. Not all of them have been brought back into line. Those who relinquish control must constantly work to persuade others.
