Wie du eine QA-Kultur in deinem Unternehmen aufbaust

Der Aufbau einer Qualitätskultur bedeutet, dass sich ein Unternehmen vom ad-hoc-Test, der von der Einhaltung von Terminen abhängig ist, hin zu einem gemeinsamen Verständnis von Qualität entwickelt, das alle Rollen umfasst: Entwickler, Product Owner, Stakeholder und Tester gleichermaßen. Dazu muss man herausfinden, was jede Gruppe unter Qualität versteht, diese Ansichten in eine sichtbare Strategie umsetzen und Prozessänderungen schrittweise einführen, damit sich die Teams ohne Widerstand oder Burnout anpassen können.

Das Wichtigste in Kürze

• QS-Fachleute sind Feedbackgeber für alle Entwicklungsteams, nicht nur für Tester, und diese umfassendere Rolle macht Qualitätsverbesserungen im gesamten Unternehmen möglich.
• Die Einführung zu vieler Änderungen auf einmal führt zu Ermüdung und Widerstand im Team; eine bedeutende Änderung pro Quartal, die vor der nächsten vollständig gemessen wird, hält die Akzeptanz stabil.
• Qualitätsmängel als finanzielle Kosten zu betrachten, indem man berechnet, was die Behebung eines Fehlerzustands in der Spätphase kostet, ist das Argument, das die Unternehmensbeteiligten von Skepsis zu Investitionsbereitschaft bewegt.
• Indem man alle von einer Veränderung betroffenen Personen vor der Einführung konsultiert und sie Teile davon mitgestalten lässt, werden aus potenziellen Verweigerern Teilhaber, die sich für den neuen Ansatz einsetzen.
• Die Sichtbarkeit der QS-Arbeit durch regelmäßige Berichte und Status-Updates, die Tabellen und klare Metriken verwenden, schließt die Lücke zwischen dem, was Tester tun, und dem, was Management und Stakeholder tatsächlich sehen.

QA ist Feedback, nicht nur Testen

Qualitätssicherung ist die Funktion, die jedem Entwicklungsteam Feedback gibt, und nicht ein Schritt, der nur Tests am Ende durchführt. Diese Unterscheidung ist entscheidend dafür, wie eine Qualitätskultur in einem Unternehmen aufgebaut wird.

Filip Leszek Barszcz arbeitet in der Finanzbranche in den Bereichen Devisenhandel, Fintech, Mobil- und Websysteme und sucht sich absichtlich Unternehmen aus, die mit ihrem QS-Ansatz Probleme haben. Das Muster, das er außerhalb der Testing-Community sieht, ist immer wieder dasselbe: Die Leute gehen davon aus, dass QA Testen bedeutet, Punkt. Sie unterscheiden oft nicht einmal in ihren Köpfen zwischen einem Tester und einem QA-Ingenieur.

Der Job ist viel breiter angelegt als das. Ein QA gibt Feedback, und zwar nicht immer nur gutes. Schlechte Nachrichten sind Teil der Arbeit. Der nützliche Rahmen ist eine doppelte Position: die letzte Verteidigungslinie für das Unternehmen und die erste Verteidigungslinie für den Kunden. Wenn du beides gleichzeitig innehast, geht es nicht mehr darum, sich durch Bildschirme zu klicken.

Das hat sich in den letzten zehn Jahren geändert. Vor zehn Jahren bestand die Arbeit darin, manuell zu testen und Probleme zu melden, und das war’s. Jetzt gibt es mehr Aufgaben und eine größere Reichweite, was bedeutet, dass ein QA nicht nur seine eigenen Prozesse verbessern kann, sondern auch die Prozesse anderer Teams.

Wie ein Unternehmen ohne QS-Kultur tatsächlich aussieht

Ein Unternehmen ohne QS-Kultur arbeitet mit ad-hoc-Tests unter Termindruck. Etwas muss innerhalb von drei Tagen ausgeliefert werden, also setzen die Mitarbeiter alle Ressourcen ein, die sie haben. Die Arbeit wird in kurzen, intensiven Schüben erledigt.

Diese Intensität hat ihren Preis. Hyperfokus in wenigen Tagen kann QS-Spezialisten in Richtung Burnout treiben, weil die Arbeitsbelastung weit über das hinausgeht, was verkraftbar ist.

Das technische Bild, das sich dahinter verbirgt, ist unterschiedlich, und Filip hat beide Extreme erlebt. Ein Unternehmen hatte starke Unit- und Integrationstests, aber eine schwache Ende-zu-Ende-Abdeckung und schwache manuelle Discovery-Tests. In einem anderen Unternehmen gab es nur Unit-Tests, keine Integrations- oder E2E-Schicht, und fast die gesamte Qualität wurde auf die manuellen Tester abgewälzt.

Da die Lücken unterschiedlich sind, gibt es keine einheitliche Lösung. Jedes Unternehmen bringt etwas Einzigartiges mit, und der Einstiegspunkt besteht darin, zu befunden, wo eine gute Praxis für das jeweilige Produkt greifen kann.

Warum jeder im Unternehmen etwas anderes unter “Qualität” versteht

Das erste Hindernis für eine Qualitätskultur ist, dass das Wort “Qualität” für jede Rolle etwas anderes bedeutet. Stakeholder, Eigentümer von Komponenten, Produktverantwortliche und technische Leiter haben jeweils ihre eigene Sichtweise und bemerken selten, dass die anderen eine andere haben.

Die Stakeholder in einem Unternehmen interessierten sich für die Betriebszeit. Sie wollten wissen, wie lange das System offen blieb, um Geld zu verdienen, und sie betrachteten das Zeitfenster und nicht das Problem eines einzelnen Kunden.

Eine Ebene tiefer ging es den Geschäftsinhabern um das Kundenerlebnis. Sie wollten, dass das Produkt reibungslos, intuitiv und freundlich zu bedienen ist. Manchmal kam die Leistung zur Sprache, aber ihr Augenmerk lag darauf, wie sich der Kunde bei der Nutzung des Produkts fühlt.

Die erste Aufgabe besteht also darin, diese Ansichten zu erfassen. Sprich mit Leuten aus verschiedenen Positionen, schreibe auf, was jede Gruppe unter Qualität versteht, und erstelle eine Tabelle: Entwickler sehen das so, Product Owner anders, Stakeholder wieder anders. Dann übersetze die Hoffnungen jeder Gruppe in die QA-Sprache. Das Ergebnis dieser Übersetzung ist eine Roadmap, die zeigt, was die Leute tatsächlich erwarten.

Wie du den Fall aufbaust, bevor du etwas änderst

Die Unternehmensleitung dazu zu bringen, die QS-Arbeit zu finanzieren, beginnt mit dem Vergleich, nicht mit der Theorie. Konkurrenten werben oft mit ihrer Reife in Sachen Qualität, einschließlich der formalen TMMi-Stufen, und sie machen keinen Hehl daraus. Wenn du dein Produkt, deine Einnahmen und deine Reife mit denen deiner Konkurrenten vergleichst, wird die Geschäftsseite aufhorchen.

Die Kosten sind das zweite Argument. Zeig, wie viel Geld in die Behebung von Fehlerzuständen in der Spätphase der Entwicklung fließt. Filip stellt eine geschätzte Berechnung vor, die auf öffentlichen Gehaltsdaten beruht, und nennt dann eine Zahl für ein einzelnes Problem, zum Beispiel 15.000 Euro für die Behebung. Die Reaktion ist vorhersehbar: wie und warum. Die Fragen eröffnen das Gespräch.

Von dort aus zeigst du die Einsparungen auf. Wenn du das Testen von einer späten in eine frühere Umgebung verlegst, beginnt das Unternehmen, das Geld zu zählen, das es behält. Sobald Geld gespart wird, gibt es auch Geld zum Investieren.

Ein Proof of Concept macht aus dem Argument einen Beweis. In Filips aktuellem Unternehmen wurde ein POC mit einem Team zusammen mit Entwicklern und Komponentenbesitzern durchgeführt. Die Ergebnisse waren überzeugend genug, um die Lösung auf alle Teams auszuweiten, und die Geschäftsleitung stellte daraufhin mehr Budget zur Verfügung, weil sie sehen konnte, dass das Produkt ein höheres Niveau erreichte. Durch weniger Rollbacks und weniger Kundenprobleme konnten sich die Mitarbeiter auf ihre eigentliche Arbeit konzentrieren.

Stakeholder finanzieren, was sie sehen können

Sichtbarkeit ist das, was aus einem skeptischen Unternehmen einen willigen Investor macht. Wenn die QS-Kultur fehlt, sieht das Unternehmen die QS-Arbeit gar nicht und wird deshalb auch nicht dafür bezahlen.

Die Berichterstattung schließt diese Lücke, und das Format ist wichtiger, als die QS-Leute erwarten. Stakeholder und Führungskräfte reagieren auf Tabellen mit Farben. Ein so gestalteter Wochen- oder Monatsbericht, der zeigt, wie die Dinge aus ihrer Sicht aussehen, macht sie bereit zu investieren.

Nach sieben Monaten kontinuierlicher Berichterstattung in seinem jetzigen Unternehmen war das Unternehmen bereit, Qualität zu finanzieren, weil der Zweck und der Wert endlich klar vor Augen waren.

Sichtbarkeit wirkt auch in die andere Richtung. Nutze sie, um den Entwicklern und anderen Mitwirkenden Anerkennung zu zollen, nicht nur dem QA-Team. Wenn du die Anstrengungen lobst, die außerhalb des QA-Teams unternommen wurden, stärkt das den Teamgeist innerhalb der Abteilung, und das ist genauso wichtig wie jede andere Metrik.

Beginne mit den Aufräumarbeiten in deinem eigenen Garten

Die ersten Änderungen sollten ausschließlich in der QA selbst vorgenommen werden, denn das sind die Quick Wins. Beobachte und analysiere deine eigene QS-Arbeit und behebe dann, was du allein beheben kannst.

Ein paar konkrete Maßnahmen sind am Anfang am wichtigsten:

• Schränke die Anzahl der Prioritäten ein, damit sie überschaubar bleiben, und definiere, was die einzelnen Prioritäten von der Unternehmensseite her bedeuten.
• Kündige den Status des Testens laut an: Wenn eine Umgebung empfindlich und wichtig ist, bitte die Leute darum, die Arbeit nicht zu unterbrechen.
• Füge den Versionshinweisen einen Regressionsstatus und eine Umfangscheckliste hinzu, damit die Informationen nicht verloren gehen.

Das meiste davon ist die Weitergabe von Informationen, die vorher stecken geblieben sind. Wenn ein Informationsfluss blockiert ist, hilft es der QA und allen nachgelagerten Abteilungen, ihn wieder freizugeben.

Die Kosten sind im Vergleich zum Ertrag gering. Zwei bis vier Stunden pro Woche, um Informationen von einem Ort zum anderen zu verschieben, plus ein kurzes Telefonat, um den aktuellen Stand zu erklären, spart vielen Leuten echte Arbeit und lässt sie sich auf andere Dinge konzentrieren.

Diese kleinen Verbesserungen schaffen auch neue Rollen. Ein Tester ist für den Regressionsstatus zuständig, ein anderer für die Checkliste und die Entwickler für einen Teil der Checkliste. Das Modell ist pro Tag um 1 Prozent besser. Rechnet man das auf ein Jahr hoch, ist die Veränderung groß.

Wie man eine große Änderung einführt, ohne das Team zu zerschlagen

Eine große Veränderung braucht ein Anpassungsfenster, kein Einführungsdatum. Filip hat sich drei Monate Zeit für die große Workflow-Änderung genommen, die er gerade durchführt, und er hat alle, die von der Änderung betroffen sein werden, konsultiert, bevor er sie einführte.

Durch die Konsultation kannst du Widerstand in Eigenverantwortung umwandeln. Die Produktverantwortlichen fügten ein Treffen hinzu, um die Fehlersuche zu erweitern. DevOps fügte der Checkliste einen Schritt hinzu. Die Eigentümer der Komponenten fragten nach zusätzlichen Umgebungen. Die Kernidee blieb dieselbe, aber jede betroffene Gruppe gestaltete einen Teil davon, so dass jeder von ihnen zu einem Teileigentümer wurde.

Widerstand entsteht meist aus Unwissenheit. Menschen wehren sich gegen etwas, das sie nicht kennen. Deshalb muss der neue Arbeitsablauf vorgestellt und geteilt werden, bevor jemand gebeten wird, ihn zu unterschreiben. Der Ablauf wurde von oben nach unten abgesegnet: zuerst der technische Stammesführer, dann die darunter liegende Ebene, dann die darunter liegende Ebene.

Freiwilligkeit beschleunigt die Annahme. Ein proaktives Team erklärte sich bereit, den neuen Arbeitsablauf frühzeitig zu testen, und nach einem Monat war das Ergebnis stark genug, um darüber zu berichten. Ein zweites Team bat daraufhin darum, vor dem geplanten Termin 2026 beginnen zu dürfen, weil es nicht hinter das Team zurückfallen wollte, mit dem es konkurriert.

Der Instinkt, alles in einer Woche zu erledigen, ist hier der falsche. Die Schocktherapie funktioniert bei kleinen Dingen; eine Workflow-Änderung in dieser Größenordnung wäre zu viel, um sie in diesem Teil des Jahres zu bewältigen. Bei kleinen Änderungen ist es einfacher, um Vergebung zu bitten als um Erlaubnis, also teste sie selbst. Große Veränderungen brauchen den langsameren Weg.

Staple die Änderungen nicht schneller, als die Leute sie verkraften können

Zu viele Änderungen auf einmal führen zu einem müden, instabilen Team, das anfängt, sich gegen alles zu wehren. Filip hat diesen Fehler gemacht, und die Lektion ist hängen geblieben.

Seine Regel lautet nun: eine signifikante Veränderung pro Quartal, wobei “signifikant” noch nicht gleichbedeutend mit enorm ist. Führe eine Änderung ein, die etwas verbessert, messe ihre Auswirkungen und bereite dann die nächste vor. Wenn die erste Änderung nicht richtig eingearbeitet ist, wartet die nächste.

“Wenn wir zu viele Änderungen einführen, macht das nur ein müdes Team. Dafür fehlte es an Stabilität, und die Leute fangen einfach an, sich gegen die Veränderungen zu wehren.” Filip Leszek Barszcz

Stabilität nach einer Veränderung ist das Signal, dass du dich wieder bewegen kannst. Ohne diese Pause, in der sich die Dinge beruhigen, landet jede neue Veränderung auf einer wackeligen Basis.

Wann ist die Qualitätsarbeit “erledigt”?

Es gibt keine feste Ziellinie, denn das richtige Maß an Qualität hängt vom Kunden und dem Kontext ab. Was in einem Unternehmen passt, ist in einem anderen Abfall.

CI/CD zeigt die Fallstricke auf. In einem Team war ein CI/CD-Ansatz sinnvoll. In einem anderen Unternehmen war CI/CD aufgrund schwerer rechtlicher Verpflichtungen ein erstrebenswertes Ziel, aber aus Sicht der QS-Kosten hätte es Ressourcen für wenig Ertrag verbrannt.

Das Entscheidungsinstrument ist eine Kosten-Aufwand-Ansicht: Wie viel Zeit wird investiert und was kommt zurück? Deshalb wird so viel Zeit in die Analyse und Diskussion mit Geschäfts- und Technikverantwortlichen gesteckt, um zu verstehen, ob eine Praxis aus Sicht der Entwicklung und DevOps überhaupt anwendbar ist und welches Geschäftsergebnis sie bringt.

Überall gilt derselbe Standard, auch wenn sich die Antwort ändert. Ein Unternehmen in einem Markt kann nicht mit einem Unternehmen im Finanzbereich verglichen werden: andere Ergebnisse, andere Mentalität, anderes Gewicht der Arbeit. Letztlich zahlt das Unternehmen für die Auslieferung eines Produkts, und jede Qualitätsentscheidung muss einen Wert für dieses Produkt schaffen.