Wie du eine QA-Kultur in deinem Unternehmen aufbaust

Eine QA-Kultur aufzubauen heißt, ein Unternehmen weg vom Ad-hoc-Testen unter Termindruck und hin zu einem gemeinsamen Qualitätsverständnis aller Rollen zu bringen: Entwickler, Product Owner, Stakeholder und Tester gleichermaßen. Dafür erhebt man, was jede Gruppe unter Qualität versteht, übersetzt diese Sichten in eine sichtbare Strategie und führt Prozessänderungen schrittweise ein, damit sich die Teams ohne Widerstand und ohne Burnout anpassen können.

Das Wichtigste in Kürze

• QA-Fachleute geben allen Entwicklungsteams Feedback, nicht nur den Testern. Erst diese breitere Rolle macht Qualitätsverbesserung im ganzen Unternehmen möglich.
• Zu viele Änderungen auf einmal machen ein Team müde und erzeugen Widerstand. Eine größere Änderung pro Quartal, deren Wirkung vor der nächsten gemessen wird, hält die Akzeptanz stabil.
• Qualitätsmängel als Kosten darzustellen, etwa mit einer Rechnung, was ein spät gefundener Fehlerzustand kostet, bringt die Geschäftsseite von Skepsis zu Investitionsbereitschaft.
• Wer alle Betroffenen vor einer Änderung einbindet und sie Teile davon mitgestalten lässt, macht aus möglichen Gegnern Mitverantwortliche, die den neuen Ansatz vertreten.
• Regelmäßige Berichte und Statusmeldungen mit Tabellen und klaren Kennzahlen machen QA-Arbeit sichtbar und schließen die Lücke zwischen dem, was Tester tun, und dem, was Management und Stakeholder davon sehen.

QA ist Feedback, nicht nur Testen

Qualitätssicherung ist die Funktion, die jedem Entwicklungsteam Feedback gibt, und kein Schritt, der am Ende nur noch Tests laufen lässt. Von dieser Unterscheidung hängt ab, wie eine QA-Kultur im Unternehmen entsteht.

Filip Leszek Barszcz arbeitet in der Finanzbranche, in Devisenhandel, Fintech, Mobil- und Websystemen, und sucht sich bewusst Unternehmen aus, deren QA-Ansatz hakt. Außerhalb der Testing-Community sieht er immer wieder dasselbe Muster: Die Leute setzen QA mit Testen gleich, Punkt. Oft unterscheiden sie nicht einmal gedanklich zwischen einem Tester und einem QA-Engineer.

Die Aufgabe ist breiter. Wer in der QA arbeitet, gibt Feedback, und nicht immer gutes. Schlechte Nachrichten gehören zur Arbeit. Hilfreich ist das Bild einer Doppelrolle: letzte Verteidigungslinie für das Unternehmen und erste Verteidigungslinie für die Kunden. Wer beides zugleich ausfüllt, klickt sich nicht mehr nur durch Bildschirme.

Das hat sich im letzten Jahrzehnt verschoben. Vor zehn Jahren hieß die Arbeit: manuell testen, Probleme melden, fertig. Heute gibt es mehr Aufgaben und mehr Reichweite. QA-Leute können nicht nur die eigenen Prozesse verbessern, sondern auch die anderer Teams.

Wie ein Unternehmen ohne QA-Kultur aussieht

Ein Unternehmen ohne QA-Kultur testet ad hoc und unter Termindruck. Etwas muss in drei Tagen raus, also werfen alle darauf, was sie an Leuten haben. Die Arbeit kommt in kurzen, heftigen Schüben.

Diese Intensität hat ihren Preis. Wer ein paar Tage im Hyperfokus arbeitet, rutscht als QA-Spezialist Richtung Burnout, weil die Last weit über das hinausschießt, was sich auf Dauer tragen lässt.

Technisch sieht es darunter ganz unterschiedlich aus, und Filip hat beide Extreme erlebt. Ein Unternehmen hatte starke Unit- und Integrationstests, aber schwache End-to-End-Abdeckung und kaum manuelles exploratives Testen. Ein anderes hatte nur Unit-Tests, keine Integrations- oder E2E-Ebene, und fast die ganze Qualitätslast lag bei den manuellen Testern.

Weil die Lücken verschieden sind, gibt es keine Einheitslösung. Jedes Unternehmen bringt etwas Eigenes mit. Der Einstieg besteht darin, herauszufinden, wo eine gute Praxis bei genau diesem Produkt greifen kann.

Warum jede Rolle etwas anderes unter Qualität versteht

Das erste Hindernis für eine Qualitätskultur: Das Wort „Qualität“ bedeutet für jede Rolle etwas anderes. Stakeholder, Komponentenverantwortliche, Product Owner und technische Leitung haben jeweils ihre eigene Sicht und merken selten, dass die anderen eine andere haben.

In einem Unternehmen interessierten sich die Stakeholder für die Verfügbarkeit. Sie wollten wissen, wie lange das System geöffnet war, um Geld zu verdienen, und schauten auf das Zeitfenster, nicht auf das Problem eines einzelnen Kunden.

Eine Ebene darunter ging es dem Fachbereich um das Kundenerlebnis. Das Produkt sollte reibungslos, intuitiv und angenehm zu bedienen sein. Performance kam manchmal zur Sprache, im Mittelpunkt stand aber, wie sich der Kunde bei der Nutzung fühlt.

Am Anfang steht also, diese Sichten zu erfassen. Sprich mit Leuten aus verschiedenen Positionen, schreib auf, wie jede Gruppe Qualität versteht, und bau eine Tabelle: Entwickler sehen es so, Product Owner anders, Stakeholder noch einmal anders. Dann übersetze die Erwartungen jeder Gruppe in QA-Sprache. Heraus kommt eine Roadmap dessen, was die Leute tatsächlich erwarten.

Wie du die Geschäftsleitung von Investitionen in Qualität überzeugst

Wer Budget für QA-Arbeit will, beginnt mit dem Vergleich, nicht mit Theorie. Wettbewerber werben oft mit ihrer Qualitätsreife, auch mit formalen TMMi-Stufen, und machen kein Geheimnis daraus. Stell dein Produkt, deine Erlöse und deine Reife neben ihre, und die Geschäftsseite hört zu.

Die Kosten sind das zweite Argument. Zeig, wie viel Geld in die Behebung spät gefundener Fehlerzustände fließt. Filip legt eine Schätzung auf Basis öffentlicher Gehaltsdaten vor und nennt dann eine Zahl für ein einzelnes Problem, zum Beispiel 15.000 Euro für die Behebung. Die Reaktion ist vorhersehbar: Wie das, und warum? Mit diesen Fragen beginnt das Gespräch.

Von da aus zeigst du die Einsparung. Wird früher getestet, also in einer Umgebung vor der späten, fängt das Unternehmen an, das Geld zu zählen, das es behält. Und wo Geld gespart wird, ist Geld zum Investieren da.

Ein Proof of Concept macht aus dem Argument einen Beleg. In Filips aktuellem Unternehmen lief ein POC mit einem Team, gemeinsam mit Entwicklern und Komponentenverantwortlichen. Die Ergebnisse überzeugten so sehr, dass die Lösung auf alle Teams ausgerollt wurde. Die Geschäftsleitung gab danach mehr Budget frei, weil sie sah, wie das Produkt ein höheres Niveau erreichte. Weniger Rollbacks und weniger Kundenprobleme machten den Kopf frei für die eigentliche Arbeit.

Stakeholder finanzieren, was sie sehen

Sichtbarkeit macht aus einem skeptischen Unternehmen einen willigen Investor. Wo QA-Kultur fehlt, sieht das Unternehmen die QA-Arbeit gar nicht und zahlt deshalb auch nicht dafür.

Berichte schließen diese Lücke, und das Format zählt mehr, als QA-Leute denken. Stakeholder und Führungskräfte reagieren auf farbige Tabellen. Ein wöchentlicher oder monatlicher Bericht in diesem Stil, der zeigt, wie die Lage aus ihrer Sicht aussieht, macht sie bereit zu investieren.

Nach sieben Monaten kontinuierlicher Berichte war Filips jetziges Unternehmen bereit, Qualität zu finanzieren, weil Zweck und Nutzen endlich vor Augen lagen.

Sichtbarkeit wirkt auch in die andere Richtung. Nutze sie, um Entwickler und andere Beteiligte zu würdigen, nicht nur das QA-Team. Wer die Leistung von außerhalb der QA lobt, stärkt den Teamgeist in der ganzen Einheit, und das zählt so viel wie jede Kennzahl.

Fang bei der eigenen QA an

Die ersten Änderungen sollten ganz in der Hand der QA liegen, denn das sind die Quick Wins. Beobachte und analysiere deine eigene QA-Arbeit und behebe dann, was du allein beheben kannst.

Ein paar konkrete Schritte bringen am Anfang den größten Nutzen:

• Begrenze die Zahl der Prioritäten, damit sie übersichtlich bleiben, und leg fest, was jede Priorität aus Sicht des Fachbereichs bedeutet.
• Sag den Teststatus laut an: Wenn eine Umgebung empfindlich und wichtig ist, bitte die Leute, nicht zu deployen und die Arbeit zu stören.
• Nimm einen Regressionsstatus und eine Checkliste zum Umfang in die Release Notes auf, damit die Information nicht verloren geht.

Meist geht es darum, Informationen weiterzugeben, die vorher hängen geblieben sind. Wo ein Informationsfluss blockiert ist, hilft es der QA und allen nachgelagerten Abteilungen, ihn wieder freizumachen.

Der Aufwand ist klein im Vergleich zum Ertrag. Zwei bis vier Stunden pro Woche, um Informationen von einer Stelle an die andere zu bringen, plus ein kurzer Call zum aktuellen Stand, sparen vielen Leuten echte Arbeit und machen sie frei für anderes.

Diese kleinen Verbesserungen schaffen auch neue Zuständigkeiten. Ein Tester verantwortet den Regressionsstatus, eine andere die Checkliste, die Entwickler einen Teil davon. Das Prinzip: jeden Tag 1 Prozent besser. Übers Jahr gerechnet ist die Veränderung groß.

Eine große Änderung einführen, ohne das Team zu überfordern

Eine große Änderung braucht ein Anpassungsfenster, keinen Stichtag. Filip hat sich für die große Workflow-Änderung, die er gerade umsetzt, drei Monate Zeit genommen und vor dem Start alle einbezogen, die davon betroffen sind.

Durch Einbindung wird aus Widerstand Mitverantwortung. Die Product Owner ergänzten ein Meeting, um die Bug-Triage auszuweiten. DevOps fügte der Checkliste einen Schritt hinzu. Die Komponentenverantwortlichen wünschten sich zusätzliche Umgebungen. Die Kernidee blieb gleich, aber jede betroffene Gruppe gestaltete ein Stück davon mit und wurde so selbst Teil der Verantwortung.

Widerstand entsteht meist aus Unkenntnis. Menschen wehren sich gegen das, was sie nicht kennen. Deshalb muss der neue Ablauf vorgestellt und geteilt werden, bevor irgendwer zustimmen soll. Die Freigabe lief von oben nach unten: zuerst der technische Tribe Lead, dann die Ebene darunter, dann die nächste.

Freiwillige beschleunigen die Einführung. Ein proaktives Team erklärte sich bereit, den neuen Ablauf früh auszuprobieren, und nach einem Monat war das Ergebnis stark genug, um darüber zu berichten. Ein zweites Team bat daraufhin, schon vor dem geplanten Termin 2026 starten zu dürfen, weil es nicht hinter das Team zurückfallen wollte, mit dem es im Wettbewerb steht.

Der Reflex, alles in einer Woche durchzuziehen, ist hier falsch. Schocktherapie funktioniert bei kleinen Dingen. Eine Workflow-Änderung dieser Größe wäre in diesem Teil des Jahres zu viel. Bei kleinen Änderungen ist es leichter, um Verzeihung zu bitten als um Erlaubnis, also probier sie einfach aus. Große Änderungen brauchen den langsameren Weg.

Wie viele Veränderungen ein QA-Team gleichzeitig verkraftet

Zu viele Änderungen auf einmal machen ein Team müde und instabil, und irgendwann wehrt es sich gegen alles. Filip hat diesen Fehler selbst gemacht, und die Lektion sitzt.

Seine Regel heute: eine größere Änderung pro Quartal, wobei „größer“ noch nicht „riesig“ heißt. Führe eine Änderung ein, die etwas verbessert, miss ihre Wirkung und bereite dann die nächste vor. Ist die erste noch nicht richtig angekommen, wartet die nächste.

“Wenn wir zu viele Änderungen einführen, hast du am Ende nur ein müdes Team. Dafür fehlte die Stabilität, und die Leute fangen einfach an, sich gegen die Änderungen zu wehren.”

(Filip Leszek Barszcz)

Stabilität nach einer Änderung ist das Zeichen, dass du wieder loslegen kannst. Ohne diese Pause, in der sich alles setzt, landet jede neue Änderung auf wackeligem Grund.

Wann ist die Qualitätsarbeit „fertig“?

Eine feste Ziellinie gibt es nicht, denn das richtige Qualitätsniveau hängt von Kunde und Kontext ab. Was in einem Unternehmen passt, ist im nächsten Verschwendung.

CI/CD zeigt die Falle. In einem Team war ein CI/CD-Ansatz sinnvoll. In einem anderen Unternehmen war volles CI/CD wegen schwerer rechtlicher Auflagen zwar ein Wunschziel, hätte aus Sicht der QA-Kosten aber viel Aufwand für wenig Ertrag verbrannt.

Das Entscheidungswerkzeug ist eine Kosten-Nutzen-Sicht: Wie viel Zeit geht hinein, und was kommt zurück? Deshalb fließt so viel Zeit in Analyse und Gespräche mit Fach- und Technikverantwortlichen, um zu klären, ob eine Praxis aus Sicht von Entwicklung und DevOps überhaupt anwendbar ist und welches Geschäftsergebnis sie bringt.

Der Maßstab ist überall derselbe, auch wenn die Antwort wechselt. Ein Unternehmen in einem Markt lässt sich nicht mit einem aus der Finanzbranche vergleichen: andere Ergebnisse, andere Mentalität, anderes Gewicht der Arbeit. Am Ende zahlt das Unternehmen dafür, ein Produkt auszuliefern, und jede Qualitätsentscheidung muss für dieses Produkt einen Wert schaffen.

Häufig gestellte Fragen

Ist ein Tester dasselbe wie ein QA-Ingenieur?

Nein. Außerhalb der Test-Community werden beide oft als ein und derselbe Job betrachtet, aber Qualitätssicherung ist eine Feedback-Funktion für jedes Entwicklungsteam, kein Schritt, bei dem am Ende Tests durchgeführt werden. Ein nützlicher Ansatz ist eine doppelte Rolle: letzte Verteidigungslinie für das Unternehmen, erste Verteidigungslinie für den Kunden. Seit Mitte der 2010er Jahre hat sich die Rolle vom manuellen Testen und der Fehlermeldung hin zur Verbesserung der Prozesse anderer Teams erweitert.

Warum sind sich die Leute im selben Unternehmen uneinig darüber, was als gute Qualität gilt?

Weil jede Rolle ihre eigene Definition hat und selten bemerkt, dass die anderen anders denken. In einem Unternehmen konzentrierten sich die Stakeholder auf die Verfügbarkeit und das Zeitfenster, in dem Geld verdient werden kann, während sich die Geschäftsverantwortlichen eine Ebene tiefer um ein reibungsloses, intuitives Kundenerlebnis kümmerten. Der praktische Schritt besteht darin, mit Menschen aus verschiedenen Positionen zu sprechen, jede Sichtweise in eine Tabelle einzutragen und diese Erwartungen in die Sprache der Qualitätssicherung zu übersetzen. Das Ergebnis ist ein Fahrplan der tatsächlichen Erwartungen.

Wie lässt sich die Investition in Qualität finanziell begründen?

Beziehe einen Fehlerzustand auf eine konkrete Zahl. Eine Schätzung auf Basis öffentlicher Gehaltsdaten kann zeigen, was die Behebung eines einzelnen Problems in einer späten Entwicklungsphase kostet (zum Beispiel 15.000 Euro), und die vorhersehbare Reaktion ist die Frage nach dem „Wie“ und „Warum“, was das Gespräch in Gang bringt. Ein Vergleich mit der Konkurrenz hilft ebenfalls, da Mitbewerber mit ihrer Reife werben, einschließlich formaler TMMi-Stufen. Zeige dann, was durch die Verlagerung des Tests in eine frühere Entwicklungsumgebung eingespart wird.

Auf welche Art von QA-Berichten reagieren die Stakeholder aus dem Geschäft tatsächlich?

Tabellen mit farblichen Hervorhebungen und klaren Metriken, die wöchentlich oder monatlich bereitgestellt werden und aus der Perspektive der Stakeholder statt aus der der Tester verfasst sind. In einem Unternehmen gingen sieben Monate konsequenter Berichterstattung voraus, bevor das Unternehmen bereit war, Arbeit zur Verbesserung der Qualität zu finanzieren, da der Zweck und der Nutzen endlich sichtbar wurden. Nutze dieselben Berichte, um Entwickler und andere Mitwirkende zu würdigen, nicht nur das QA-Team.

Welche Verbesserungen der Qualität kann ein QA-Team ohne Zustimmung anderer Abteilungen in Angriff nehmen?

Diejenigen, die vollständig unter der Kontrolle des QA-Teams liegen, denn das sind auch die „Quick Wins“. Schränke die Anzahl der Prioritäten ein und definiere, was jede einzelne aus geschäftlicher Sicht bedeutet. Gib den Status der Testumgebung laut bekannt und bitte die Leute, keine Deploys durchzuführen, wenn sie instabil und wichtig ist. Füge den Release-Notes einen Regressionsstatus und eine Checkliste zum Umfang hinzu.

Lohnt sich der Aufwand, QA-Informationen zu teilen?

Ja, denn die Kosten sind im Vergleich zum Nutzen gering. Etwa zwei bis vier Stunden pro Woche, die dafür aufgewendet werden, Informationen von einem Ort zum anderen zu übertragen, plus ein kurzes Telefonat zur Erläuterung des aktuellen Zustands, sparen vielen Beteiligten echte Arbeit. Der größte Teil des Nutzens entsteht dadurch, dass zuvor blockierte Informationsflüsse wieder freigegeben werden, was der Qualitätssicherung und allen nachgelagerten Abteilungen hilft.

Wie viele Prozessänderungen kann ein Team auf einmal verkraften?

Eine größere Änderung pro Quartal, und „größer“ bedeutet noch lange nicht „riesig“. Führe eine Änderung ein, miss ihre Wirkung und bereite dann die nächste vor. Wenn die erste Änderung noch nicht richtig verankert ist, wartet die nächste. Werden Änderungen zu schnell hintereinander eingeführt, führt das zu einem erschöpften, instabilen Team, das anfängt, sich gegen alles zu wehren. Stabilität nach einer Änderung ist das Signal, dass du wieder weitermachen kannst.

Brauchen kleine und große Prozessänderungen denselben Einführungsansatz?

Nein. Kleine Änderungen können einfach getestet werden, da es hier einfacher ist, um Verzeihung zu bitten als um Erlaubnis. Eine große Änderung am Arbeitsablauf erfordert eine Anpassungsphase von etwa drei Monaten und die Rücksprache mit allen Betroffenen, bevor sie in Betrieb geht. Produktverantwortliche haben die Fehler-Triage erweitert, DevOps hat einen Schritt zur Checkliste hinzugefügt, Komponentenverantwortliche haben um mehr Umgebungen gebeten, und so wurde jede Gruppe mitverantwortlich.