From the test factory to QA coaching

QA coaching as a central service means that a small quality assurance team does not test itself, but advises projects, reviews test plans and maintains standards together with a community of practice. Instead of being a controller, the team works on an equal footing with projects, provides templates and helps with the selection of external service providers.

Key Takeaways

• The QA team of the Federal Employment Agency’s IT system house has eight people who support around 100 to 120 IT applications without sending testers to projects themselves.
• The replacement of a Word test manual of several hundred pages was only successful when the team openly asked the projects about their pain points and created a community of practice.
• The change from “test directive” to “test guardrails” was not a mere renaming: less binding requirements, greater acceptance and voluntary test plan reviews replaced the former control function.
• The voluntary nature of the reviews has a downside: some projects used the elimination of the obligation as an excuse and have since dispensed with test plans altogether.

From controller to coach: why acceptance is more important than the hook

Centralized quality assurance works better as a coaching service than as a controlling authority. The Federal Employment Agency’s IT system house has made this transition over the past ten years or so. Today, a team of eight people is responsible for testing and quality assurance issues for around 100 to 120 IT applications without having to send staff to the projects themselves.

The decisive difference lies in the role. A team that gives the release hook is feared and bypassed. A team that advises at eye level is brought into the projects. Christian Ulrich describes this effect directly: “With topics such as a quality-of-test check or the review of test plans, the team now establishes a better connection to the projects.

How a 300-page test manual became a test guard rail

The old test manual was a thick Word document and nobody read it. Acceptance was correspondingly low. The conversion did not begin with a new template, but with a question to those affected.

The team recruited volunteers from every area of the IT system house for a community of practice. At the first meeting, the question was: Where does this document hurt you? Which of the requirements can you not comply with? The initial reaction was mistrust. The same department had been monitoring for years, now it was asking about pain points.

For years they’ve been pestering us, and now they’re coming across like this. That was really the icebreaker, when they realized they really meant it.

Christian Ulrich

It was precisely this serious change of perspective that was the turning point. The Word document became a leaner structure in Confluence. The strict “test directive” became “test guard rails”, which allow more leeway and require less detailed description.

What must remain: legal requirements as a hard limit

Not everything could be streamlined. As a public authority, the IT system house is subject to regulations and legal requirements that must remain in the document. This has been the conflict for years: low acceptance on the one hand, non-negotiable obligations on the other.

The solution lay in separation. What is mandatory is justified as such and remains in the document. Everything else was opened up. The remaining guard rails have become fewer and are still binding, but they have been agreed with the stakeholders. This means that the team no longer needs a supervisory role because the guidelines are accepted.

To ensure that the streamlining process does not freeze, the team regularly reviews the legal texts. If there is a need for change, it brings the community back together and looks at what impact this has on the rest of the regulations.

How central QA gets involved in the projects

The central unit is not involved in project staffing, but seeks contact early on. As soon as a project is restaffed, the team offers its services: a template for the test plan, help with test questions, support in selecting external service providers.

This early involvement has a clear objective. The idea of testing and quality should be anchored in the project right from the start, even without the small unit being able to assign its own staff. When selecting external service providers, the team asks specific questions, the answers to which often indicate whether a provider is a good fit for the project.

The test execution itself remains within the teams. The teams are put together in such a way that every discipline is represented, even if the requirement is that everyone works T-shaped. Testers are part of these teams and carry out the tests. Acceptance takes place at the end of the sprint, often with representatives from the specialist departments.

Load and performance tests are an exception. There is a separate central unit for carrying these out, to which a team can hand over this task.

Testing quadrants instead of test levels: Developer tests are part of the concept

The change from classic test levels to testing quadrants has visibly brought development tests into the test plan. In the past, many chapters were filled with test levels, today the testing quadrants structure the concept.

This has a practical effect. Many of the development tests are in the first quadrant, so they automatically appear in the test plan. The concept is no longer a document solely for downstream test activities, but also reflects what developers contribute.

This is based on the hope of synergies. If team members with an affinity for testing and development have a common strategy, quality can be ensured earlier. The goal is a shift left: testing things as early as possible because errors are then cheaper and quicker to rectify.

When voluntariness is misused as an excuse

A voluntary review does not replace the mandatory hook one-to-one. This is where the team made a mistake. As long as the review was mandatory, no one got through the release without the hook. When the review was switched to a voluntary basis, some projects used this as an excuse to do their own thing.

The team is making adjustments here. Not all projects have been recaptured, but the need for minimal documentation of the test plan is increasingly being seen. Giving up control requires persuasion, and that is not done with the first step.

The perceived problem lies in the exchange between disciplines. Too often, testers and development experts do not know enough about each other. The attitude “I don’t do testing, the tester does it” or “Unit testing is enough” persists. The team still sees room for improvement here.

What other organizations can take away from this

Even an organization close to the authorities can live agility and lean quality assurance. The path taken by the IT system house shows that the greatest leverage lies not in a better document, but in a changed role and the genuine involvement of those affected.

If you are sitting in front of an unread test manual, the first sensible question is not “How do we shorten it?”, but “Where does it hurt the teams?”. A community of practice turns those affected into co-creators. Mandatory parts remain justified, the rest becomes negotiable.

The transition from a controlling to a coaching role is not a foregone conclusion. It requires trust, which must first be built up, and it brings setbacks, for example when voluntariness is used as an excuse. It is possible to share such experiences, even beyond your own organization.