Ein leichtgewichtiges Testkonzept ist ein modularer Baukasten aus kurzen, verlinkten Themenheften, der gezielt für einzelne Situationen genutzt wird statt als einmaliges Gesamtdokument. Jeder Baustein enthält eine Anwendergeschichte, eine Beschreibung des Themas, ein Self-Assessment zur Reifegradmessung und konkrete Verbesserungsschritte.
Das Wichtigste in Kürze
- Der QS-Baukasten des Bundesverwaltungsamts ersetzt schwergewichtige Testhandbücher von teils 300 Seiten durch modulare, kurze Bausteine, die Mitarbeitende situativ und selbstständig nutzen können.
- Traceability zwischen Testfällen und Anforderungen von Anfang an aufzubauen kostet wenig Aufwand, nachträglich einzuführen hingegen ist eine Riesenarbeit.
- Eine monatliche Community of Practice mit regelmäßig 70 bis 80 Teilnehmenden hat im Bundesverwaltungsamt mehr Wissenstransfer bewirkt als Schulungen, weil Projektteams dort konkrete Lösungen direkt untereinander austauschen.
- Externes Testen durch Dienstleister hat dazu geführt, dass das Test-Know-how intern verloren gegangen ist, was den Baukasten als Werkzeug zur Rückgewinnung dieses Wissens notwendig macht.
- Der Baukasten soll in Q1 unter einer Creative-Commons-Lizenz auf einer Open-Code-Plattform veröffentlicht werden, damit auch andere Behörden davon profitieren und eigene Anpassungen beisteuern können.
Warum schwergewichtige Testkonzepte in der Verwaltung scheitern
Hunderte Seiten Testhandbuch landen in der Schublade und werden nie gelesen. Genau das ist das Muster, das Behörden bei klassischen Testkonzepten und Teststrategien immer wieder erleben. Die Dokumente entstehen, weil ein Prozess sie verlangt, nicht weil jemand sie braucht.
Das Bundesverwaltungsamt ist traditionell auf das V-Modell XT des Bundes verpflichtet. Das funktioniert gut, solange Anforderungslagen klar sind, etwa wenn ein Gesetz oder eine Verordnung ein bestimmtes Fachverfahren vorgibt. Schwierig wird es, sobald sich die Lage schnell ändert.
Die sogenannte Flüchtlingskrise 2015 war für Oliver Kortendick und sein Team der Auslöser zum Umdenken. Ein Verfahren musste in kurzer Zeit stehen, obwohl der Gesetzesbeschluss noch nicht erfolgt war. Man begann mit der Entwicklung und passte das Verfahren laufend an die Gesetzeslage an. Mit einem starren Vorgehen wäre das kaum gelungen.
Eine Großorganisation ist das natürliche Anti-Pattern fuer Agilität
Das Bundesverwaltungsamt verkörpert fast jede Bedingung, die agiles Arbeiten erschwert. Über 6000 Mitarbeitende, verteilt über 20 Liegenschaften in Deutschland, dazu zahlreiche externe Dienstleister, eine differenzierte Hierarchie und Fachbereiche, die von der IT getrennt sind. Das erzeugt Schwerfälligkeit und Langsamkeit.
Hinzu kommt die schiere Vielfalt der Arbeit: über 150 Fachverfahren, vom Kleinstverfahren bis zum Riesenprojekt. Alle rufen nach Standardisierung, aber bei dieser Spannweite ist Standardisierung schwer zu erreichen.
Agile Transformation funktioniert in diesem Umfeld nur als Weg der kleinen Schritte. Simone Mester und Oliver beschreiben keinen Big Bang und kein eingekauftes Framework, sondern einen langsamen Wandel. Der ist auch nach Jahren nicht abgeschlossen, aber er bewegt sich.
Test-Know-how darf nicht nur bei den Externen liegen
Wenn externe Dienstleister über Jahre den Großteil der Testarbeit übernehmen, verliert die eigene Organisation ihr Wissen. Genau das war ein zentrales Problem im Bundesverwaltungsamt. Die Frage wurde: Wie kommt das Test-Wissen wieder zu den eigenen Kollegen zurück?
Den Einstieg bildete eine Community of Practice, die seit über fünf Jahren besteht. Sie trifft sich sechs bis zehnmal im Jahr, regelmäßig mit 70 bis 80 Teilnehmenden. Das ist für ein freiwilliges Format ein hoher Wert.
Im Zentrum stehen Werkstattberichte. Leute aus den Projekten erzählen, was sie gemacht haben, und Kontakte entstehen. Jemand hört zu und merkt, dass ein anderes Team an genau dem Problem schon seit Monaten arbeitet. Diese pragmatische Wissensvermittlung ersetzt das Bedürfnis, in jedem Projekt alles neu zu erfinden.
Lehrbuchlösungen helfen dabei wenig, weil sie auf die Behörde oft nicht passen. Gebraucht werden Ansätze, die einmal funktioniert haben und sich woanders übernehmen lassen.
Was der QS-Baukasten ist
Der QS-Baukasten ist ein modulares Wissensmodell, aus dem du dir genau das Modul ziehst, das dein aktuelles Problem löst. Statt ein Testhandbuch von 120, 150 oder 300 Seiten durchzulesen, greifst du gezielt zu einem einzelnen Baustein, vergleichbar mit einem Heft aus einem Bücherschrank.
Inhaltlich orientiert sich der Baukasten am ISTQB-Prozessmodell, an den Software-Qualitätsmerkmalen der ISO und an der eigenen Erfahrung des Teams. Aufgesetzt ist das Ganze in Confluence, die Seiten sind untereinander verlinkt.
Die Themen decken die Praxis ab, die im Behördenbetrieb gern untergeht:
- Anforderungsmanagement
- Teststufen wie Komponenten-, Integrations- und Systemtest
- Testentwurfsverfahren
- Traceability von Testfällen zu Anforderungen
- Review-Arten
- Barrierefreiheit
- Testdaten
Traceability ist ein gutes Beispiel für den Nutzen. Machst du sie von Anfang an, ist der Aufwand gering. Versuchst du, sie im Nachhinein einzuziehen, von den Testfällen zurück zu den Anforderungen, wird daraus eine Riesenarbeit.
Wie ein Baustein aufgebaut ist
Jeder Baustein folgt derselben Dramaturgie und holt damit verschiedene Lerntypen ab. Oben steht die ISTQB-Definition, damit alle Beteiligten ein gemeinsames Wording haben. Gerade bei wechselnden Dienstleistern reden Menschen sonst phänomenal aneinander vorbei.
Danach folgt eine Anwendergeschichte. Diese Geschichten sind erfunden, hätten so aber im Amt passieren können. Wer sie liest, findet einen leichten Einstieg ins Thema und schmunzelt dabei. Die Hoffnung dahinter: Wer einmal schmunzelt, liest auch den Rest.
Es folgt eine möglichst einfache Beschreibung, warum es das Thema überhaupt gibt. Manche Inhalte werden zusätzlich über kurze YouTube-Videos vermittelt, weil zwei Minuten Video für viele angenehmer sind als ein langer Text.
Zu jedem Baustein gibt es ein Reifegradmodell, das auf genau dieses Thema zugeschnitten ist. Es reicht von “initial”, wo nur ad hoc etwas passiert, bis zu kontrollierten Stufen. So kannst du dich selbst einordnen und siehst, wo du stehst.
Am Ende stehen Verlinkungen in die Tiefe, von Buchtipps über Internetquellen bis zu wissenschaftlichen Artikeln. Eine kleine Wissensdatenbank fängt Themen auf, die für einen eigenen Baustein zu klein sind. Dazu kommen Vorlagen, die stark nachgefragt werden, etwa für Protokolle oder für die Frage, wie man überhaupt einen Testfall schreibt.
Begründungszusammenhänge sind wichtiger als Vorschriften
Menschen verbessern sich nur, wenn sie wissen, warum. Diese Erkenntnis kam aus vielen Feedbackrunden mit den eigenen Mitarbeitern und prägt den Baukasten. Die Leute wollen den Zusammenhang verstehen, nicht eine weitere Anweisung befolgen.
Das Wissensmodell ist deshalb vielschichtig. Du kannst an der Oberfläche bleiben und bekommst einen schnellen Überblick. Oder du gehst über den Hypertext in die Tiefe, bis hinein in wissenschaftliche Artikel.
Dahinter steht eine kulturelle Frage. Im klassischen Silo saß jeder für sich, warf sein Arbeitsergebnis über den Zaun und sah den Gesamtprozess nicht mehr. Agil verlangt das Gegenteil.
Im Agilen willst du gerade, dass das Team eine gemeinsame Verantwortung hat und sich auf höchste Produktqualität committet. Das heißt, jeder muss aus dem Silo raus und sein Wissen und seine Energie einbringen. Oliver Kortendick
Wie der Baukasten im Projekt wirkt
Seit Juli ist der Baukasten im Feldeinsatz. Dafür wurde bewusst ein Projekt in Schieflage gewählt: mit Kommunikationsstörungen, bei denen Leute teilweise nicht mehr miteinander redeten.
Dieses Projekt hatte keine risikobasierte Teststrategie. Es gab keine Prioritäten, getestet wurde mit der Gießkanne über alles gleichmäßig. Die Folge waren erhebliche Verzögerungen.
Aus dem Baukasten wurden drei Felder herausgearbeitet, in denen sich das Projekt bis Ende November verbessern konnte. Diese Punkte waren zum größten Teil bereits abgearbeitet. Parallel misst das Team regelmäßig und simpel die Stimmung: Wie fühlst du dich gerade? Diese Werte verbesserten sich, und genau das ist für Teambuilding und gute Zusammenarbeit relevant.
Übungen schließen die Lücke zwischen Lesen und Können
Manche Menschen lernen erst, wenn sie etwas selbst ausprobieren. Deshalb wird es zu jedem Baustein eine vierstündige Übung geben. Drei sind fertig, weitere folgen im nächsten Jahr.
Eine Übung kann sehr konkret sein, etwa einen Testfall mit Grenzwertanalyse auf Papier schreiben, während die Begleiter daneben sitzen und sich die Teilnehmenden untereinander abstimmen. Du kannst jemandem ein Verfahren hundertmal erklären, manche müssen es einfach einmal machen.
Die Übungen sind nach Rollen geschnitten. Das BVA arbeitet mit gewohnten Rollen wie Komponentenverantwortlicher oder Projektleiter. Du musst nicht alle Übungen machen, sondern fünf oder sechs, die zu deiner Rolle passen und dich weiterbringen.
Berichte muss man einfordern, nicht nur empfangen
Berichtswesen heißt nicht nur, selbst Berichte zu schreiben, sondern Berichte entgegenzunehmen, zu verstehen und aktiv einzufordern. Das ist ein Schwerpunkt für die operative Ebene.
Das Gegenbeispiel ist verbreitet: Externe Dienstleister liefern ein Konvolut aus HTML-Seiten nach dem Motto “viel hilft viel”. Damit bleibst du allein und kommst nur unwesentlich weiter. Der bessere Weg ist, klar zu sagen, welche Informationen du in welcher Form brauchst.
Warum das Bundesverwaltungsamt den Baukasten veröffentlicht
Der QS-Baukasten soll im ersten Quartal unter einer Creative-Commons-Lizenz erscheinen, aller Voraussicht nach auf der Open-Code-Plattform. Du kannst ihn dann ansehen, herunterladen und nach deinen Bedürfnissen verändern.
Die Logik dahinter ist einfach. In den Baukasten ist viel Arbeit und Geld geflossen, andere Behörden haben dieselben Probleme, und es gibt bereits etliche Anfragen. Was funktioniert, soll auch anderen zugutekommen.
Schön wäre es, wenn Änderungen zurückfließen, weil das Team selbst weiterlernen will. Haftung oder Gewährleistung kann es dabei nicht übernehmen. Und manchmal liegt der Gewinn schon darin, aus den Fehlern eines anderen zu lernen.
