QS-Coaching als zentrale Dienstleistung bedeutet, dass ein kleines Qualitätssicherungsteam nicht selbst testet, sondern Projekte berät, Testkonzepte reviewt und Standards gemeinsam mit einer Community of Practice pflegt. Statt Kontrolleur zu sein, arbeitet das Team auf Augenhöhe mit Projekten, liefert Vorlagen und hilft bei der Auswahl externer Dienstleister.
Das Wichtigste in Kürze
- Das QS-Team des IT-Systemhauses der Bundesagentur für Arbeit betreut mit acht Personen rund 100 bis 120 IT-Anwendungen, ohne selbst Tester in Projekte zu entsenden.
- Die Ablösung eines mehrere hundert Seiten starken Word-Testhandbuchs gelang erst, als das Team die Projekte offen nach ihren Schmerzpunkten fragte und eine Community of Practice daraus entstehen ließ.
- Der Wechsel von “Testdirektive” zu “Testleitplanken” war keine reine Umbenennung: weniger verbindliche Vorgaben, stärkere Akzeptanz und freiwillige Testkonzept-Reviews ersetzten die frühere Kontrollfunktion.
- Die Freiwilligkeit der Reviews hat eine Kehrseite: Manche Projekte nutzten den Wegfall der Pflicht als Ausflucht und verzichten seitdem ganz auf Testkonzepte.
Vom Kontrolleur zum Coach: warum Akzeptanz wichtiger ist als der Haken
Eine zentrale Qualitätssicherung funktioniert besser als Coaching-Angebot denn als Kontrollinstanz. Das IT-Systemhaus der Bundesagentur für Arbeit hat diesen Wechsel über rund zehn Jahre vollzogen. Heute betreut ein Team von acht Leuten die Test- und Qualitätssicherungsthemen für etwa 100 bis 120 IT-Anwendungen, ohne dafür selbst Personal in die Projekte zu schicken.
Der entscheidende Unterschied liegt in der Rolle. Ein Team, das den Release-Haken vergibt, wird gefürchtet und umgangen. Ein Team, das auf Augenhöhe berät, wird in die Projekte geholt. Christian Ulrich beschreibt diesen Effekt direkt: Mit Themen wie einem Quality-of-Test-Check oder dem Review von Testkonzepten baut das Team heute einen besseren Draht zu den Projekten auf.
Wie ein 300-Seiten-Testhandbuch zu Testleitplanken wurde
Das alte Testhandbuch lag als dicker Word-Schinken vor und niemand las es. Die Akzeptanz war entsprechend niedrig. Der Umbau begann nicht mit einer neuen Vorlage, sondern mit einer Frage an die Betroffenen.
Das Team gewann aus jedem Bereich des IT-Systemhauses Freiwillige für eine Community of Practice. Im ersten Treffen lautete die Frage: Wo tut euch dieses Dokument weh? Was könnt ihr von den Vorgaben gar nicht einhalten? Die Reaktion war zunächst Misstrauen. Jahrelang hatte dieselbe Stelle kontrolliert, jetzt fragte sie nach Schmerzpunkten.
Jahrelang haben sie uns getriezt, und jetzt kommen sie so rüber. Das war dann wirklich der Icebreaker, wo sie gemerkt haben, die meinen das wirklich so.
Christian Ulrich
Genau dieser ernst gemeinte Perspektivwechsel war der Wendepunkt. Aus dem Word-Dokument wurde eine schlankere Struktur in Confluence. Aus der strengen “Testdirektive” wurden “Testleitplanken”, die mehr Spielraum lassen und weniger Detailbeschreibung erzwingen.
Was bleiben muss: gesetzliche Vorgaben als harte Grenze
Nicht alles ließ sich verschlanken. Als Behörde unterliegt das IT-Systemhaus Regularien und gesetzlichen Vorgaben, die im Dokument bleiben müssen. Das war über Jahre der Konflikt: niedrige Akzeptanz auf der einen Seite, nicht verhandelbare Pflichten auf der anderen.
Der Ausweg lag in der Trennung. Was Pflicht ist, wird als solche begründet und bleibt drin. Alles andere wurde geöffnet. Die verbliebenen Leitplanken sind weniger geworden und nach wie vor verbindlich, aber sie sind mit den Stakeholdern abgestimmt. Damit braucht das Team keine Kontrolleursrolle mehr, weil die Vorgaben akzeptiert sind.
Damit die Verschlankung nicht einfriert, prüft das Team regelmäßig die Gesetzestexte. Ergibt sich Änderungsbedarf, holt es die Community wieder zusammen und schaut, welche Auswirkungen das auf das übrige Regelwerk hat.
Wie sich die zentrale QS in die Projekte einklinkt
Die zentrale Einheit ist an der Projektbesetzung nicht beteiligt, sucht aber früh Kontakt. Sobald ein Projekt neu gestafft wird, bietet das Team seine Dienstleistungen an: eine Vorlage fürs Testkonzept, Hilfe bei Testfragen, Unterstützung bei der Auswahl externer Dienstleister.
Diese frühe Beteiligung hat ein klares Ziel. Der Test- und Qualitätsgedanke soll von Anfang an im Projekt verankert sein, auch ohne dass die kleine Einheit eigenes Personal abstellen kann. Bei der Auswahl externer Dienstleister stellt das Team gezielt Fragen, an deren Antworten sich oft schon ablesen lässt, ob ein Anbieter zum Projekt passt.
Die Testdurchführung selbst bleibt in den Teams. Die Teams sind so zusammengestellt, dass jede Disziplin vertreten ist, auch wenn der Anspruch lautet, dass jeder T-shaped arbeitet. Tester sind Teil dieser Teams und führen die Tests durch. Die Abnahme passiert am Sprintende, oft mit Vertretern der Fachbereiche.
Eine Ausnahme bilden Last- und Performance-Tests. Für deren Durchführung gibt es eine eigene zentrale Einheit, an die ein Team diese Aufgabe abgeben kann.
Testquadranten statt Teststufen: Entwicklertests gehören ins Konzept
Der Wechsel von klassischen Teststufen zu Testquadranten hat die Entwicklungstests sichtbar ins Testkonzept geholt. Früher füllten viele Kapitel den Umgang mit Teststufen, heute strukturieren die Testquadranten das Konzept.
Das hat einen praktischen Effekt. Im ersten Quadranten stehen viele der Entwicklungstests, und damit tauchen sie automatisch im Testkonzept auf. Das Konzept ist nicht länger ein Dokument allein für nachgelagerte Testaktivitäten, sondern bildet auch ab, was Entwickler beitragen.
Dahinter steht die Hoffnung auf Synergien. Wenn test- und entwicklungsaffine Teammitglieder eine gemeinsame Strategie haben, lässt sich Qualität früher sichern. Das Ziel ist ein Shift Left: Dinge so früh wie möglich testen, weil Fehler dann günstiger und schneller zu beheben sind.
Wenn Freiwilligkeit als Ausflucht missbraucht wird
Ein freiwilliges Review ersetzt den verpflichtenden Haken nicht eins zu eins. Genau hier verschätzte sich das Team. Solange das Review Pflicht war, kam niemand ohne den Haken durch den Release. Als das Review auf freiwillige Basis umgestellt wurde, nutzten einige Projekte das als Ausflucht und machten ihr eigenes Ding.
Das Team steuert hier nach. Nicht alle Projekte sind wieder eingefangen, aber die Notwendigkeit einer Minimaldokumentation des Testkonzepts wird zunehmend gesehen. Wer Kontrolle aufgibt, muss Überzeugungsarbeit leisten, und die ist mit dem ersten Schritt nicht erledigt.
Die wahrgenommene Baustelle liegt im Austausch zwischen Disziplinen. Zu oft wissen Test- und Entwicklungsexperten noch nicht genug voneinander. Die Haltung “Testen mache ich nicht, das macht der Tester” oder “Unit-Test reicht doch völlig aus” hält sich hartnäckig. Hier sieht das Team weiterhin Luft nach oben.
Was andere Organisationen daraus mitnehmen können
Auch eine behördennahe Organisation kann Agilität und schlanke Qualitätssicherung leben. Der Weg des IT-Systemhauses zeigt, dass der größte Hebel nicht in einem besseren Dokument liegt, sondern in einer geänderten Rolle und in echter Beteiligung der Betroffenen.
Wenn du vor einem ungelesenen Testhandbuch sitzt, ist die erste sinnvolle Frage nicht “Wie kürzen wir das?”, sondern “Wo tut es den Teams weh?”. Eine Community of Practice macht aus Betroffenen Mitgestalter. Pflichtteile bleiben begründet, der Rest wird verhandelbar.
Der Übergang von der Kontroll- zur Coaching-Rolle ist kein Selbstläufer. Er kostet Vertrauen, das man erst aufbauen muss, und er bringt Rückschläge, etwa wenn Freiwilligkeit als Ausrede dient. Der Austausch über solche Erfahrungen ist möglich, auch über die eigene Organisation hinaus.
