Qualitätssicherung in agilen Großunternehmen bedeutet mehr als Testen: Qualität wird im gesamten Entwicklungszyklus mitgedacht, von der Anforderung bis zum Betrieb. Teams arbeiten eigenverantwortlich, Quality Specialists agieren als Coaches und Sparringspartner. Schnittstellen zwischen Teams werden über Consumer Driven Contracts automatisiert abgesichert. Qualitätsbewusstsein wird durch Gilden, Quality Buddies und Schulungsangebote in alle Teams getragen.
Das Wichtigste in Kürze
- Qualität ist nicht Aufgabe einer dedizierten Testperson, sondern muss im kompletten Entwicklungs-Lifecycle von allen Teammitgliedern mitgedacht und mitgetragen werden.
- Die Quality-Buddy-Rolle ermöglicht es Teams ohne dedizierten Quality Specialist, trotzdem jemanden zu haben, der aktiv Qualitätsthemen triggert und als Multiplikator zwischen Team und Gilde fungiert.
- Consumer Driven Contracts sind bei Otto zum Standard-Task geworden, sobald eine neue Schnittstelle zwischen zwei Teams entsteht, und lösen damit die Schnittstellentests weitgehend automatisiert.
- Das erklärte Ziel eines Quality Specialists ist es, sich selbst überflüssig zu machen: Erst wenn das Team dasselbe Know-how und Mindset mitbringt, ist die Aufgabe erfüllt.
Vom separaten Testteam zur Qualitätsverantwortung im Team
Otto hat das klassische Testteam aufgelöst und die Verantwortung für Qualität in die Entwicklungsteams verlagert. Früher arbeitete das Unternehmen wasserfallartig: Ein eigenes Testteam wartete, bis die Entwicklung eine Software lieferte, führte dann manuelle fachliche Tests durch und meldete sein Feedback zurück.
Der Wandel begann, als Otto den Shop und später die App komplett selbst entwickelte und betrieb. Mit dieser Eigenentwicklung verschob sich das Mindset, und das separate Testteam ging in den Entwicklungsteams auf. Die Tester übernahmen zunächst weiter ihre gewohnten Testaktivitäten, saßen aber direkt im Team, mit kürzeren Feedback-Schleifen.
Dieser erste Schritt war noch nicht das Ziel. Dominique Petrich, Quality Manager bei Otto, beschreibt das Zielbild anders: weg von den klassischen ISTQB-Rollen wie Tester und Testmanager, hin zu Sparringspartnern, Kommunikatoren, Moderatoren und Coaches im Team.
Qualität entsteht über den gesamten Lifecycle, nicht nur im Test
Qualität muss über den kompletten Lebenszyklus einer Anforderung mitgedacht werden, von der Konzeption über den Livegang bis in den Betrieb. Das Testen selbst ist nur ein Teil davon. Das eigentliche Ziel ist breiter: Prozesse, das Team und das Zusammenspiel gehören genauso dazu.
Daraus folgt eine ungewöhnliche Selbstdefinition der Qualitätsrolle. Ein Quality Manager arbeitet darauf hin, sich im Team überflüssig zu machen.
Ich bin fertig, wenn meine Arbeitskolleginnen und Arbeitskollegen im Team das gleiche Know-how haben wie ich, das gleiche Mindset, das gleiche Bewusstsein, die Awareness für Qualität. — Dominique Petrich
Der Rollenname spiegelt diesen Wandel wider. Aus dem bereichsinternen Quality Specialist wurde später der Technical Quality Manager, vor allem um eine einheitliche Bezeichnung im Unternehmen zu schaffen.
Warum Eigenverantwortung der Teams die Transformation getragen hat
Die agile Transformation bei Otto kam nicht als Anweisung von oben, sondern wurde von allen Beteiligten mitgestaltet. Diese gemeinsame Gestaltung erhöht die Akzeptanz, weil niemand einen fremden Prozess aufgedrückt bekommt.
Mit der Eigenentwicklung baute Otto die Teams cross-funktional auf. Der Anspruch dahinter: Im Team sollte grundsätzlich jeder in der Lage sein, alles mitzudenken und mitzuarbeiten. Die Optimierung hört dabei nie auf. So wie Software iterativ entsteht, entwickelt sich auch ein Team iterativ weiter.
Eigenverantwortung bringt Pflichten mit sich. Die Teams wollen diese Verantwortung aber leben und sich selbst verbessern. Genau dieser Optimierungswille sorgt dafür, dass Qualitätsthemen aus dem Team heraus angegangen werden, statt von außen verordnet zu werden.
Wie das Know-how zum Testen im Team verteilt wird
Der erste Hebel war die Verteilung von Test-Know-how auf alle Schultern. Statt dass eine QS-Person allein Tests erdenkt, schreibt und ausführt, lernen alle im Team, das zu tun. Eine einzelne Testressource wäre sonst ein Bottleneck.
Die konkreten Themen sind anfangs handwerklich: Wie schreibe ich Tests, mit welchen Frameworks, wie führe ich sie aus. Von dort aus arbeitet sich das Team schrittweise weiter durch den Lifecycle.
Otto schreibt den Teams dabei keinen festen Tech-Stack vor. Die Teams sind weitgehend autonom und entscheiden selbst über Programmiersprachen, Frameworks und Tools. Nur bestimmte Dinge sind fest gesetzt und werden zentral organisiert.
So sieht der Arbeitsprozess in den Teams aus
Otto arbeitet mit einem Mix aus Scrum und Kanban, intern Scrumban genannt. Die Teams haben sich die Praktiken herausgesucht, die für sie passen, statt ein Framework eins zu eins abzubilden.
In Dominiques Team läuft die Arbeit über ein Board mit klaren Phasen: Analyse, Entwicklung, eine Abnahme, Livegang und ein anschließender Review-Prozess. Stories kommen jederzeit in den priorisierten Backlog und werden abgearbeitet. Dedizierte Sprint-Plannings mit festen Vorab-Commitments gibt es dort nicht.
Geschätzt wird trotzdem, aber mit einem anderen Zweck. Die Schätzung dient nur dazu, Diskussionsbedarf aufzudecken. Gehen die Schätzungen weit auseinander, haben die Teammitglieder ein unterschiedliches Verständnis der Story und müssen noch einmal sprechen. Die Schätzwerte selbst stehen nicht in den Stories und werden nicht als Erfolgsmaß genutzt.
Der Zwei-Wochen-Rhythmus bleibt erhalten, um die Teams synchron zu halten und übergeordnete Planungen herunterzubrechen, vom Unternehmen über den Bereich bis ins einzelne Team.
Eine Quality-Gilde gegen verlorene Synergien
Bei rund 60 Teams im E-Commerce-Bereich entsteht ein Risiko: Synergien gehen verloren, und Qualität wird reaktiv statt präventiv behandelt. Ein einmal aufgesetzter Prozess läuft, wird nicht mehr angefasst, und erst nach einem größeren Fehler schaut jemand auf die Ursachen.
Genau das soll präventives Qualitätsdenken verhindern. Als Antwort gründeten vier Kollegen die Quality-Gilde, ein regelmäßiges Austauschformat für alle, die sich im Bereich mit Qualität beschäftigen. Dort geht es um aktuelle Herausforderungen, gegenseitige Unterstützung, Schnittstellen und voneinander Lernen.
Die Zahlen zeigen, warum ein übergreifendes Format nötig ist: Rund 15 Quality Specialists stehen etwa 60 Teams gegenüber. Nicht jedes Team hat also eine dedizierte QS-Person, und das ist bewusst so akzeptiert.
Quality Buddy und Security Champion: Rollen, die jeder übernehmen kann
Für Teams ohne dedizierte QS-Person hat Otto die Rolle des Quality Buddy geschaffen. Diese Person hält im Team das Fähnchen für Qualität hoch, triggert das Thema bei Auffälligkeiten und wirkt als Multiplikator zwischen Team und Gilde.
Die Rolle ist nicht an einen Beruf gebunden. Ein Quality Buddy kann ein Entwickler sein, ein fachlicher Experte oder jemand aus dem UX-Bereich, unabhängig von der eigentlichen Rolle.
Dasselbe Muster wiederholt sich bei der Sicherheit. Jedes Team hat einen Security Champion, der in ein eigenes Austauschformat geht und Security-Themen stärker im Team verankert.
Ergänzt wird das durch konkrete Angebote: zwei Workshops, in denen Teams gezielt ihre Qualitätsthemen bearbeiten, ein Schulungsangebot für neue Kollegen und gelegentliche Vorträge, teils mit externen Speakern.
Warum Grundlagen wiederholt werden müssen
Selbst erfahrene Entwickler profitieren davon, Testgrundlagen regelmäßig aufzufrischen. Beim Onboarding setzt man oft voraus, dass neue Kollegen ein bestimmtes Mindset und Wissen mitbringen. Trotzdem lohnt es sich, Basics wieder anzusprechen.
Dazu gehören Äquivalenzklassen, Entscheidungsbäume oder das saubere Erstellen von Testfällen. Diese Konzepte haben die meisten schon gehört, geraten im Alltag aber in den Hintergrund. Das Feedback dazu ist eindeutig: Es war gut, das mal wieder bewusst gehört zu haben.
Wie Otto zwischen Teams testet: Consumer Driven Contracts
Für die Tests zwischen zwei Teams setzt Otto auf Consumer Driven Contracts, kurz CDC. Diese automatisierten Schnittstellentests laufen in den CI/CD-Pipelines der jeweiligen Teams.
Das ist inzwischen Selbstverständlichkeit. Wer eine neue Schnittstelle zu einem anderen Team aufbaut, hat den automatisierten Schnittstellentest als Standard-Task im Backlog. Über einzelne oder wenige Teams hinweg erreicht Otto so einen sehr hohen Automatisierungsgrad.
Schwieriger wird es jenseits von zwei Teams. Sobald End-to-End-Testing über mehrere Bereichsgrenzen hinweg nötig wird, steigt der Anteil manueller Arbeit und Kommunikation deutlich. Eine fertige Lösung dafür gibt es noch nicht, und genau hier sieht Otto eine seiner größten offenen Baustellen.
Nicht-funktionale Anforderungen über spezialisierte Teams absichern
Security, Last, Performance und Verfügbarkeit deckt Otto über dedizierte Teams ab, kombiniert mit Rollen in den Produktteams. Für Security gibt es ein eigenes Team mit verpflichtenden Schulungen für alle.
Bei der technischen Absicherung greift Otto auf Tooling der genutzten Plattformen zurück. Da alle Repositories in GitHub liegen, sind GitHub-Services für alle Teams verpflichtend. Die Infrastruktur in der Amazon Cloud liefert automatisierte Scannings, die Teams auf Auffälligkeiten hinweisen.
Für Last und Performance betreibt ein eigenes Team übergreifende Tests, die regelmäßig gegen die Umgebung laufen. Fällt etwas auf, geht das Team auf die betroffenen Produktteams zu. Diese können mit den Last-Test-Experten zusätzlich eigene Tests für ihre Services konzipieren.
Der Shop darf nicht ausfallen, sonst wird es teuer. Deshalb gehören Alarming und Monitoring in die Eigenverantwortung jedes Teams.
Disaster Recovery als wiederkehrende Übung
Einmal im Jahr findet ein Disaster Recovery Day statt. Dabei wird ein Ernstfall nachgestellt, etwa ein kompromittierter AWS-Account, der einen kompletten Neuaufbau erzwingt. Ziel ist es, hochautomatisiert und in Zusammenarbeit mit anderen Teams alle Schnittstellen möglichst schnell wiederherzustellen.
Diese Tage decken auf, wo noch Lücken klaffen. Inzwischen führen einzelne Teams solche Übungen zusätzlich regelmäßig selbst durch, um den Prozess weiter zu automatisieren und für den Ernstfall schneller zu werden.
Usability über UX-Rollen, A/B-Tests und echtes Kundenfeedback
Usability sichert Otto über UX-Spezialisten direkt in den Frontend-Teams. UX-Designer und UX-Manager tragen Usability- und Barrierefreiheits-Anforderungen ins Team, egal ob für App oder Webshop.
Dazu kommt systematisches Kundenfeedback. Otto arbeitet mit regelmäßigen Befragungen und mit A/B-Testing, bei dem Features zunächst nur für einen Teil der Kunden ausgerollt werden. Gemessen wird beides: wie die Features performen und wie das Feedback ausfällt.
Auf dem Campus in Hamburg betreibt Otto ein eigenes UX-Lab. Dort werden echte Kunden eingeladen, schauen sich Features am Bildschirm an, werden getrackt und geben direkt zurück, ob sie etwas intuitiv bedienen konnten.
Statische Analyse liegt in der Verantwortung der einzelnen Teams
Beim Umgang mit statischer Analyse gibt es bei Otto keinen einheitlichen Standard. Manche Teams nutzen sie stark, andere kaum. Auch das ist Ausdruck der Teamautonomie.
Konkret heißt das: Manche Teams setzen Linting ein und lassen Testabdeckung eher lokal prüfen, etwa beim Pairing oder durch die QS-Person. Andere Teams bauen Quality Gates in ihre CI/CD-Pipelines ein, definieren eine Mindest-Testabdeckung und lassen automatisierte Analysen darüber laufen.
Diese Bandbreite ist gewollt. Statt die statische Analyse von außen hart vorzuschreiben, bleibt die Entscheidung beim Team.
Die größten offenen Baustellen für die nächsten Jahre
End-to-End-Testing über mehrere Bereichsgrenzen hinweg bleibt die größte technische Herausforderung. Großprojekte, die Shop, Backend und mehrere Bereiche betreffen, sollen mit möglichst wenig manuellem Aufwand und integriert in den agilen Prozess getestet werden. Dieses Thema wird Otto noch länger begleiten.
Daneben rückt KI in den Arbeitsalltag. Otto arbeitet bereits stark mit Algorithmen und probiert aus, wie KI die Programmierarbeit unterstützt, etwa beim Schreiben von Tests, und sammelt dazu Best Practices.
Auch neue Kanäle erzeugen Testbedarf. Shopping wird künftig nicht nur über Webshop und App laufen, sondern etwa über Smart TV oder das Auto. Jeder neue Kanal muss eingebunden, getrackt und getestet werden.
Der größte strukturelle Trend betrifft die QS-Rolle selbst. Die Zahl der QS-Spezialisten wird perspektivisch nicht mit der Zahl der Teams mitwachsen. Das Zielbild ist, dass Teams Qualität vollständig selbst tragen.
Damit verschiebt sich die Aufgabe der Quality Manager nach oben. Statt von Team zu Team zu wandern, wandern sie in die übergreifende Tätigkeit: Angebote schaffen, Teams enablen und das Qualitätsbewusstsein team- und bereichsübergreifend treiben.
