Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute bei mir zu Gast Dominik Petrich, Quality Manager bei Otto. Der eine oder andere kennt Otto vielleicht noch aus der Zeit der Versandkataloge, aber Otto hat sich den Herausforderungen der Zeit gestellt und hat es in meiner Wahrnehmung sogar geschafft,
als einer der wenigen Konzerne wirklich eine gute agile Transformation hinzubekommen. Und so betreibt Otto heute einen großen Marktplatz und hat es geschafft, sich selbst in die Neuzeit zu katapultieren. Wer Konzerne kennt, weiß, das ist nicht immer einfach. Und mit Domi spreche ich darüber, was denn das für das Testen geheißen hat. Dieser ganze agile Weg, wie man Coaching und Mentoring einbauen konnte, wie die Tester und die Teams enabled wurden, was es mit der Testautomatisierung
auf sich hat und wie Testen heute bei Otto funktioniert. Viel Spaß bei der Folge. Hallo, schön, dass du da bist. Moin, schön, dass ich da sein darf. Ja, das freut mich sehr, dass wir es geschafft haben. Wir hatten ja einige Anläufe gebraucht, um den Termin zu finden, aber das hat ja jetzt auch geklappt. Und ich finde ja, also du arbeitest ja in einem ganz spannenden Umfeld, finde ich, weil du bist bei Otto. Das kennen manche Hörer vielleicht noch
so von früher vom Katalog, als man den Katalog bekommt. Aber ihr habt euch ja als Unternehmen ja massiv gewandelt in den letzten Jahren. Und immer so, wenn ich es so mitbekomme, seid ihr auch, es wird dir so wahrgenommen, als ein Paradebeispiel für einen Konzern, der die agile Transformation lebt und gelebt hat, der das wirklich geschafft hat und nicht nur so Worthülsen um sich wirft, sondern das auch wirklich bis in die Grundfesten ins Unternehmen reingebracht hat.
Also das ist immer wieder Feedback, was ich bekomme, auch wenn ich, wenn ich sehe, wie ihr arbeitet oder was ich auch da selber wahrnehme. Und ja, und in dem Bereich, da ist natürlich für mich noch mal ganz spannend, wie sieht denn das da mit der Qualitätssicherung aus? Weil also, ich mag ihn eh schon komplex, wie man das alles auch gut unterkriegt. Aber wie macht man das dann
auch noch im Konzern, um wirklich auch ein gutes Produkt zu liefern? Und deswegen freue ich mich, dass du heute da bist, mal so einen anderen Blick auf Qualität uns zu geben, nämlich wie ihr auch Qualität lebt und wie ihr das macht. Ja, ich bin sehr gespannt. Genau, also lange Rede, kurzer Sinn. Genau, ja, lass uns da einfach direkt reingehen. Du bist ja jetzt auch schon einige Zeit lang dabei. Wenn du mal so draufschaust, was ist denn bei euch, sagen wir mal so, der Kern der
Qualität? Wie habt ihr euch organisiert? Wie macht ihr denn das eigentlich? Ja, da muss ich vermutlich ein bisschen ausholen. Aber ich, erstmal teile ich deine Wahrnehmung. Damals, als ich zu Otto gekommen bin, ist das auch unter anderem deswegen passiert, weil ich gesehen habe, auch auf einer Konferenz tatsächlich, wie weit Otto schon ist, wie weit die im Tech-Stack sind, dass Otto eben kein altmodischer Kataloghändler mehr ist, sondern tatsächlich ein Tech-Unternehmen ist und sehr
modern ist, würde ich behaupten. Und das war auch ein Grund, warum ich mich damals dann bei Otto quasi beworben habe. Genau, und jetzt bin ich seit fünf Jahren da und darf da mitmachen und meine Geschicke da unterbringen, sozusagen. Und im Prinzip haben wir genauso angefangen, wie ganz viele. Wir waren, bevor Otto den Shop und die App in Eigenentwicklung, komplett in Eigenentwicklung entwickelt und betrieben hat, waren wir auch ganz klassisch wasserfallartig unterwegs. Da gab es so
ein Test-Team, wie man das eben so kennt von damals. Die Entwicklungsteams haben Software entwickelt, die haben das dann über den Zaun geworfen und dann gab es da Tester an Tester*innen, die da getestet haben und ihr Feedback wieder kundgetan haben. Genau, und ich glaube, der Wandel hat dann eigentlich begonnen mit der Umstellung, dass Otto eben den Shop und dann später die App eben komplett selbst entwickelt hat und betrieben hat. Und da ist dann, glaube ich, auch dieser
Mindset-Shift quasi hat da stattgefunden und die agile Transformation. Und dieses Test-Team, was es da separat gab, hat sich quasi aufgelöst und die ganzen Kolleg*innen sind dann in die Teams gewandert. Und anfangs war es so, dass diese Kolleg*innen, das waren halt klassische Tester, die einfach dann in den Teams die Testeraktivitäten übernommen haben. Ganz einfach war das. Das heißt, die waren früher quasi, war das ein eigenes Test-Team, das nur darauf gewartet hat,
wann liefert die Entwicklung? Die haben eigentlich dann nur manuelle, fachliche Tests dann durchgeführt? Genau, so kann man das sagen. Ganz klassisch irgendwie wasserfallmäßig war das. Richtig. Genau. Und nachdem die dann halt rübergewandert sind in die einzelnen Teams, wie gesagt, waren die dann aber trotzdem noch irgendwie selbstverantwortlich, die Testaktivitäten
auszuführen. Also im Prinzip hat sich nicht so viel geändert, außer dass sie halt direkt in den Teams saßen und vielleicht so die Feedback-Schleife kürzer war und man eine direkte Kommunikation hatte. Aber das ist natürlich noch nicht das Zielbild gewesen und auch nicht das, wie wir uns das heute vorstellen. Denn die Rolle der Kolleg*innen hat sich dann komplett gewandelt quasi. Und wir bei uns, also ich spreche immer vom E-Commerce-Bereich bei Otto. Es gibt
andere Bereiche, die machen das vielleicht anders. Das kann ich so hundertprozentig dann auch nicht sagen, weil ich nicht alle Bereiche kenne bei Otto. Aber bei uns im E-Commerce hat sich die Rolle dann halt gewandelt und dann wurden diese Tester*innen dann Quality Specialist. So nannte sich dann diese neue Rolle. Inzwischen heißen wir Technical Quality Manager. Das wurde auch nochmal angepasst, der Name, aber nur um so eine Einheitlichkeit im Unternehmen zu schaffen. Weil dieser Quality
Specialist, die Rollenbezeichnung war quasi eine bereichsinterne Erfindung sozusagen. Aber ist auch egal. Inzwischen, um so den groben Abschluss zu finden, ist es eher so, dass wir weg von diesen klassischen ISTQB-Rollen, sage ich immer, so irgendwie Tester*innen und Testmanager und so, weg sind und sind eigentlich eher als Sparingspartner*innen, als Kommunikatoren, als Moderatoren und Coaches in den Teams unterwegs. Natürlich unterstützen wir immer noch die
klassischen Testaktivitäten. Wir arbeiten bei uns ja mit Scrum, Kanban oder so einem Mix aus allem, je nachdem wie die Teams sich das ausgedacht haben. Aber wir wollen natürlich, also Qualität ist ja ein umfassendes, es geht ja weiter darüber hinaus über die eigentliche Testaktivität, das eigentliche Testen. Qualität muss eigentlich im kompletten Lifecycle, so eine Anforderung von Konzeptionen bis Lifegang und Betrieb muss Qualität mitgedacht und mitbearbeitet werden.
Und das versuchen wir in unseren Teams zu tragen. Und ich sage immer ganz gerne, dass wenn ich in meinem Team arbeite, versuche ich mich eigentlich überflüssig zu machen. Also ich bin fertig, wenn meine Arbeitskolleg*innen in meinem Team das gleiche Know-how haben, wie ich, das gleiche Mindset mitbringen, das gleiche Bewusstsein, die Awareness für Qualität haben und den ja Qualität und Qualitätssicherung halt im kompletten Lifecycle, wie ich es gerade
gesagt habe, eine Anforderung mitleben sozusagen. Und da betrachtet man eben nicht nur die Anforderung selbst, sondern geht es auch um Prozesse und das Team im Allgemeinen und so. Ja, ja, verstehe. Das ist natürlich jetzt auch ein längerer Prozess. Ich denke, wenn man jetzt aus einem klassischen Testteam kommt, das so für sich war und da einfach gewartet hat, was dann so an Ergebnis von der Entwicklung kommt und kommt jetzt ins Team rein, übernimmt zuerst
so die Testaufgaben und dann beginnt ja so ein Wandel. Wie habt ihr den gemacht? Oder auch, wie waren die Entwickler damit zufrieden, wenn da jetzt auf einmal der Tester da ist, was machen wir mit dem? Und jetzt will der uns noch irgendwas erzählen. Wie habt ihr denn diese Transformation da hinbekommen? Ja, das ist natürlich ein laufender, langwieriger Prozess
sozusagen. Aber im Prinzip hat man damals dann in dieser agilen Transformation eben mit der kompletten Eigenentwicklung die komplette Arbeitsweise der Teams sozusagen ein bisschen überdacht. Man hat die Teamkonstellation geändert, man hat sie halt cross-funktional aufgebaut und hatte so den Anspruch dann für sich entdeckt, dass eigentlich, grob gesagt,
im Team eigentlich jeder in der Lage sein sollte, alles mitzuarbeiten und mitzudenken. Und das war dann eigentlich, ist dann quasi ein laufender Prozess, den man nach und nach immer weiter optimiert. Und in der agilen Softwareentwicklung hört die Optimierung ja nie auf. Also, man, genauso wie man Software iterativ entwickelt, entwickelt man sich als Team auch iterativ immer weiter. Und ja, genau so wurde das da auch an Hand gehandhabt. Und die Entwickler*innen haben
den Prozess mitgelebt natürlich. Also, weil es immer, also wir sind immer alle mit im Boot. Das ist ja keine Entscheidung gewesen, die von oben irgendwie kam sozusagen. Das ist eine Entscheidung gewesen oder der Prozess wurde von allen einfach getragen und mitgelebt und mitgestaltet sozusagen. Und dadurch ist natürlich die Akzeptanz dann auch höher, weil wir den Anspruch haben, dass alle Teams eigenverantwortlich sind. Und diese Eigenverantwortung bringt natürlich,
ja auch viele Pflichten für die Teams mit und eben diese Verantwortung. Aber die Teams wollen diese Verantwortung auch leben und sich selbst immer besser machen, optimieren. Und da gehört das natürlich dazu. Ich glaube, das ist schon ganz ein wesentlicher Punkt, dass die Teams das auch wollen, zum einen. Also, dass die das jetzt nicht irgendwie nur aufgedrückt bekommen und dass
sie es auch selber mitgestalten können. Weil dort, man sagt ja auch immer, dort, wo die Arbeit passiert, die wissen ja am ehesten, wo die Not am größten ist, was für Dinge man jetzt auch anpacken muss und verändern muss. Und das ist natürlich, sagen wir mal, ein Erfolgsfaktor per se, dass die Teams da auch mitwirken und das auch selber gestalten können. Richtig, richtig. Und womit habt ihr denn da so begonnen? Also, was waren denn so die ersten Dinge, wo der Wechsel
begonnen hat und wo man Dinge neu gedacht hat? Wenn du so diesen ganzen Entwicklungsprozess ansiehst? Also, ganz klassisch, wie gesagt, dadurch, dass die Kolleginnen damals ja einfach erst mal getestet haben in den Teams, ging es dann natürlich erst mal um so die ganz einfachen Dinge. Wie schreibe ich Tests? Mit was schreibe ich Tests? Was für Frameworks nutze ich? Und das
dann zu verteilen auf die Schultern sozusagen. Also, dass dann nicht die QS-ler sozusagen dafür verantwortlich sind, Tests sich auszudenken, zu schreiben und die auszuführen, sondern, dass alle enabled werden, das zu tun und die Verantwortung zu verteilen. Und dann ist das so eine grundsätzliche Überhauverteilung erst mal. Genau. Und man hat ja natürlich vorher die Herausforderung schon gesehen, dass natürlich so eine Test-Ressource quasi auch dann ein Bottleneck
sein kann und das wollte man natürlich vermeiden. Und deswegen sind da dann alle natürlich dabei und wollen das mehr. Also, intrinsische Motivation muss natürlich da sein und die ist bei jedem mehr oder weniger gegeben. Das ist auch heute noch so. Wir haben natürlich Kolleginnen, die vielleicht weniger gerne Tests schreiben als andere, das ist ganz normal. Aber die Paint-Points, die da waren, führen automatisch dazu aufgrund dieser Eigenverantwortung und diesem Optimierungswillen
sozusagen, dass man da gemeinsam daran arbeitet. Und wie gesagt, ganz klassisch geht es erstmal darum, wie generiere ich Tests, wie erstelle ich Tests, wie schreibe ich Tests, wie führe ich Tests aus. Mit sowas geht es los und dann versucht man den Lifecycle sozusagen weiter aufzubröseln, sag ich jetzt mal. Da würde ich gerne noch kurz mal ein bisschen tiefer rein, nämlich wie habt
ihr denn das in dem Prozess verankert? Auch in dem Sinne, jetzt macht ihr Plannings oder so und wie teilt ihr euch das dann auf, dass das dann auch oder wisst ihr überhaupt, was zu tun ist? Unterschiedlich. Also, unsere Teams sind grundsätzlich sehr autark oder autonom unterwegs.
Jedes Team ist für sich eben eigenverantwortlich und wir haben nicht so einen konkreten Text-Deck, wo drin steht, ihr müsst jetzt alle die Programmiersprache nutzen und ihr müsst jetzt alle die Frameworks oder Tools benutzen, sondern mehr oder weniger können das die Teams selbst. Es gibt natürlich bestimmte Dinge, die sind fest und werden auch zentral organisiert und sowas, aber grundsätzlich sind die Teams sehr autonom. Und da kann sich das jedes Team auch eigentlich
quasi selbst ausdenken, wie sie das machen. Und wie gesagt, wie ich schon sagte, wir arbeiten halt irgendwie mit Scrum und Kanban-Methoden, aber nicht so fest, wir müssen jetzt das Scrum eins zu eins abbilden, wie es theoretisch irgendwo niedergeschrieben ist, sondern wir arbeiten, also wir sagen mal so, wir arbeiten so nach Scrum-Ban. Wir haben uns da halt selbst die Prozesse so rausgeguckt, die wir nutzen wollen und für uns halt angepasst, wie es jedes Team
braucht. Und grundsätzlich nutzen wir halt ganz normales Kanban oder Scrum-Board, da ist eine Inbox, da ist eine, bei uns jetzt zum Beispiel im Team, wir haben dann, gibt es so eine Analysephase, dann kommt eine Entwicklungsphase, dann machen wir eine QA, also eine QA, eine Abnahme, dann kommt ein Live-Gang und ein Review-Prozess ist dann noch dahinter und sowas. Und so machen das
alle Teams. Es gibt, wir zum Beispiel bei mir, in meinem Team, wir machen jetzt keine speziellen Planings oder sowas, die Stories können jederzeit reinkommen und abgearbeitet werden, es gibt natürlich eine Priorisierung, einen Backlog, genau, aber wir arbeiten jetzt nicht irgendwie dediziert in diesen zwei Wochen Sprints und nehmen uns vor dem Sprint vor, wir müssen jetzt so und so
das und das schaffen und schätzen das, wie lange braucht irgendwie eine Story oder nicht. Da sind wir relativ, auch agil, also genau was das angeht, wir gucken uns Storys vorher an, wir schätzen die tatsächlich auch, aber die Schätzung nutzen wir nur um gegebenenfalls irgendwelche Diskussionspotenziale aufzudecken. Also wenn die Schätzungen weit auseinander gehen, dann müssen wir über die Story auf jeden Fall nochmal sprechen, weil dann haben alle irgendwie ein unterschiedliches Verständnis
davon und das wollen wir auflösen. Nur deswegen machen wir zum Beispiel eine Schätzung. Die Schätzung selbst steht aber gar nicht in den Stories drin, wir messen da auch nix sozusagen, wir messen so ein bisschen wie viele Storys wir so schaffen, wie viele Tickets so, genau, um dann ein bisschen einen Überblick zu haben, aber das ist für uns kein Maß, ob das jetzt ein erfolgreicher
Sprint war oder nicht. Wir arbeiten aber trotzdem in diesen zwei Wochen Rhythmus, um alle Teams irgendwie synchron zu halten und um Themenplanungen, die übergeordnet sind, also wir haben natürlich ja auch Planungen, die vom Unternehmen insgesamt kommen, die runtergebrochen wird auf unseren Bereich, die runtergebrochen wird auf Abteilungen, die runtergebrochen wird auf die Teams sozusagen,
um da eine einheitliche Synchronisation einfach zu schaffen. Aber deswegen haben wir im Theoretischen, wir arbeiten mit Jira, haben wir Sprints abgebildet, eigentlich arbeiten wir aber gar nicht so richtig
in Sprints, sondern wirklich sehr sehr sehr flexibel und agil. Ich verstehe, ja. Und wenn es jetzt quasi um die fachlichen Tests, wenn man das mal durchbricht, also das war ja das erste, womit ihr angefangen habt, wie kann man das auch automatisieren, wie kann man diese ganzen Sachen machen, wer schreibt die Tests, wie kriegt man denn, was waren denn sonst noch so für Qualitätsthemen, die ihr dann
betrachtet habt, wo du sagst, ein Quality Specialist oder wie er hieß, hat dann da so seinen Input da reingegeben und das umgesetzt mit. Genau, mit diesen Testaktivitäten und alles rund um das Testing an sich hat das begonnen und dann ging es halt, wie ich schon sagte, weiter darüber, den Lifecycle halbweiter aufzubröseln, also nicht erst in der Entwicklung einzusteigen, sondern vorher schon und auch danach die Prozesse und alles anzusehen. Und was vor allem, wo ich dann noch viel beteiligt
war und bin, aufgefallen ist, war so die Herausforderung. Erstens eben, da wir so viele Teams haben und in den letzten Jahren sind wir extrem gewachsen und die Teams, wie gesagt, sind ja sehr autonom aufgestellt, dass wir so ein bisschen das Risiko gesehen haben, dass so Synergien verloren gehen erstens und dass man vielleicht die Gefahr besteht, dass man rund um die Qualitätssicherung oder um Qualitätsthemen nicht präventiv unterwegs ist, sondern eher
irgendwie reaktiv. Also der Prozess steht irgendwann, er läuft und wir fassen ihn nicht mehr an, so nach dem Motto, ganz einfach gesagt. Und dann ist es so, jetzt haben wir vielleicht mal einen Bug oder haben vielleicht mal einen größeren Fehler und jetzt müssen wir uns diesen Prozess, woher kommt der und was sind die Ursachen und müssen dann nochmal irgendwie in die
Qualitätssicherung gehen. Und das kann ja aber nicht das Zielbild sein, sondern wir wollen ja präventiv von Anfang an Qualität mitdenken, um das zu vermeiden, dass wir irgendwie reagieren
müssen sozusagen, wenn wir natürlich möglichst viel vorher abfedern. Und da haben wir uns dann überlegt, wie wir das machen können und haben dann gesagt, ja wir müssen auf jeden Fall das Thema irgendwie erstmal teamübergreifend bei uns im Bereich treiben und haben dann, wir waren damals zu viert, haben das dann zusammengetan und unsere Köpfe zusammengeschlagen quasi und haben dann final die Quality-Gilde bei uns gegründet, was erstmal nur ein Austauschformat
ist, wo alle, die sich irgendwie mit Qualität beschäftigen bei uns im Bereich und sich regelmäßig treffen und einfach mal schnacken, was so aktuell läuft, was sind so Herausforderungen, wie kann man sich gegenseitig unterstützen, was machen die Teams, wo kann man einfach voneinander lernen, Synergien nutzen, wo gibt es Schrittstellen und so weiter. Genau, die Gilde besteht auch immer noch, dass wir uns regelmäßig austauschen und dann gab es so die Entwicklung hin, dass wir,
wie ich schon sagte, immer mehr Teams entstanden sind. Wir hatten aber nicht mehr Quality-Specialists in den Teams, sondern wir haben jetzt aktuell, ich keine Ahnung, um die 60 Teams bei uns im E-Commerce und wir sind so, weiß ich nicht, 15 Quality-Specialists. Also halt natürlich
nicht jedes Team ein Quality-Specialist. Das ist auch erstmal völlig in Ordnung, weil erstens, wie gesagt, die Teams können das selbst entscheiden, wie sie sich auch aufstellen wollen in dem Zuge und wenn die Rolle dieses Coaches, dieses Sparrings-Partner anders verteilt ist in dem Team, ist das ja auch völlig fein. Trotzdem ist es uns wichtig, dass erstens wir Vertreter haben natürlich in diesem Austausch und dass wir nicht vergessen, dieses Qualitätsbewusstsein
hochzuleben. Das war uns immer ganz wichtig. Wir müssen in den Teams verankern, dass Qualität wichtig ist und dass Qualität nicht nur Testen ist und auch in den neuen Teams und alle Teams wandeln sich ja auch, dass das immer ein Punkt ist, der jederzeit mitgedacht werden muss, wie ich schon mehrfach erwähnt habe. Und dann haben wir halt überlegt, wie können wir das den Teams vor allem mitgeben, die jetzt keine dedizierte QS-Person bei sich haben. Da haben
wir als erstes dann eine neue Rolle entwickelt. Die nennt sich Quality-Buddy. Diese Quality-Buddy ist dann Teil der Quality-Gilde auch natürlich und ist quasi so ein bisschen die Person, die in den Teams, die jetzt keinen dedizierten Quality-Specialist haben, also das Fähnchen
für Qualität einfach wählt. Das ein bisschen im Hinterkopf hat, dass diese Punkte, wenn irgendwas auffällt, im Team triggert, sich Zeit nehmen kann, sich speziell mit dem Thema Qualität und Qualitätssicherung auch zu befassen und so als Multiplikator dient ins Team und aus dem Team heraus in unsere Gilde zum Beispiel. Genau, dies haben wir als erstes eingeführt und diese Quality-Buddy-Rolle kann auch jeder oder jede im Team ausführen, unabhängig von
ihrer eigentlichen Rolle. Das können Entwickler*innen sein, das können fachliche Experten sein, das können UXler sein, alles. Genau, und dann haben wir dann noch zwei Workshops entwickelt, die den Teams helfen sollen, sich eben speziell mal in so einem Workshop mit ihren Qualitätsthemen
auseinanderzusetzen. Wir haben ein Schulungsangebot geschaffen, um neue Kolleg*innen, die bei uns im Bereich anfangen, direkt mit dem Thema quasi zu konfrontieren und einmal zu betrachten, was ist Qualität eigentlich in der Softwareentwicklung, was spielt da alles rein, was ist uns vielleicht wichtig im Bereich, was machen wir schon, welche Ansprechpartner gibt es da, welche Formate, welche, keine Ahnung, was gibt es alles, um sich eben mit Qualität zu beschäftigen
und sich da zu verbessern, um denen das von Anfang an mit an die Hand zu geben. Genau, und ja, und ab und zu bieten wir auch so Vorträge an für alle Kolleg*innen bei uns im Bereich zu speziellen Qualitätsthemen. Wenn wir da was haben, laden da mal ab und zu auch externe Speaker ein. Genau, also ganz viel, um auch übergreifend unterwegs zu sein zwischen den
Teams. Also das finde ich total spannend, dass ihr da quasi auch so an die Hand nehmt und Angebote macht, also zum einen die Gilde zum Austausch, aber auch quasi so ein Onboarding sozusagen, wie komme ich denn eigentlich dahin, qualitätsbewusst sein im Team zu leben, wie kann ich es als neuer Mitarbeiter, auch als neuer Tester vielleicht dann auch mit
ins Team reintragen. Das finde ich schon sehr erwähnenswert auch, weil das häufig wird so vorausgesetzt, also ist jetzt da, machen wir es so, steht irgendwo der Prozess, aber das wirklich auch so zu begleiten, das ist glaube ich auch ein ganz wichtiger Faktor, den ihr da umsetzt. Ja, und teilweise auch so einfach mal wieder Grundlagen anzusprechen.
Man geht irgendwie immer davon aus, wenn man neue Kolleg*innen einstellt, auch Entwickler*innen und sowas, dass die natürlich gewisse Dinge schon mitbringen, ein gewisses Mindset, aber einfach mal wieder darüber zu reden, ja wie kann ich zum Beispiel einfach mal Testfälle erstellen, was ist denn so eine Äquivalenzklasse oder sowas, wie kann ich mir mal einen Entscheidungsbaum
aufbauen. Das haben alle schon mal gehört, aber das einfach mal irgendwann mal wieder aufkommen zu lassen, mal wieder kurz irgendwie mal anzusprechen, vielleicht nochmal zu zeigen oder so, das kriegen wir auch immer wieder, das Feedback einfach mal durch Grundlagen, ja stimmt, ich mache das auch regelmäßig, aber das mal wieder dediziert einfach mal gehört zu haben, war gut, dass ich das mal wieder gehört habe sozusagen, um das ins
Bewusstsein zu kriegen. Ja, das merke ich auch immer wieder, also die Grundlagen, das kann man immer wieder wiederholen, weil das geht so leicht wieder verloren, dass man so ist bei der Grenzwerte, ich habe schon mal gehört, ja könnte ich mal machen, müsste ich mir mal überlegen, da findet man immer noch wieder spannende Testfälle, die man
dann durchführen kann. Jetzt habt ihr ja quasi so einen interkollegialen Austausch auch über die Teams hinweg, der ja jetzt eher so bei fachlicher Natur ist, würde ich sagen, also eher so ein Austausch über Testthemen und so aus, aber ich merke in so großen Unternehmen, ganz große Schwierigkeit ist eher so auch die, sagen wir mal die Testsynchronisation oder die Schnittstellen zu anderen Systemen, zu anderen Modulen, anderen Komponenten und
das zu testen, weil das so die Grenzen des eigenen Teams sprengt, weil im Team kann ich immer herumwurschteln, wie ich möchte, da mache ich mir mein Zeug, das andere Team macht sein und sobald es zusammenkommt, dann wird es schwierig. Wie habt ihr denn das gelöst
so von Qualitätsseite bei euch? Also zwischen den einzelnen Teams arbeiten wir halt ganz viel mit CDCs, mit diesen Consumer Driven Contracts, genau, also mit automatisierten Tests, die dann bei uns in den CI/CD Pipelines in den jeweiligen Teams halt laufen, genau.
Das weiß gar nicht mehr, wie das damals gekommen ist, aber inzwischen ist das so eine Selbstverständlichkeit irgendwie, also das gehört dazu, wenn ich eine neue Schnittstelle zu einem Team aufbaue, dann ist das ein Standard-Task sozusagen, der da abgearbeitet wird, wir brauchen auch automatisierte Schnittstellen-Tests und die lösen wir halt immer über diese CDCs, genau. Schwieriger wird es dann, wenn es nicht nur zwei Teams betrifft, wenn es dann wirklich
in Richtung End-to-End-Testing oder sowas geht. Gerade in großen Projekten, da haben wir auch immer noch die Herausforderung, dass oftmal viel, viel Kommunikation stattfindet, dass viel, viel manuell auch passiert. Das wünschen wir uns natürlich auch besser, weil das natürlich Zeit und dann auch Geld frisst quasi. Das ist tatsächlich auch ein
Thema, wo wir aktuell dran sind. Wie können wir, vor allem wenn es um große Projekte geht, die ganz viele Teams, nicht nur in unserem Bereich, wo dann auch Teams wieder betroffen sind, wo wir mit anderen Bereichen zusammenarbeiten, wie können wir sowas End-to-End möglichst hochautomatisiert testen, wie können wir die Aufwände verringern. Da sind wir aktuell dran, da haben wir noch nicht die perfekte Lösung. Also wie gesagt, aktuell
ist das tatsächlich noch relativ viel manueller Aufwand. So zwischen einzelnen Teams über vielleicht wenige Teams hinweg haben wir generell einen sehr, sehr hohen Automatisierungsgrad, was Schnittstellen-Tests angeht. Da sind wir sehr gut aufgestellt. Sobald es über Bereichskanzen hinausgeht und wirklich große Projekte angeht, da haben wir tatsächlich auch Herausforderungen. Ja, da seid ihr ja auch nicht alleine. Das Thema haben ja viele,
aber ich merke schon, dass ihr euch da auch gut Gedanken macht dazu. Das Spiel schwingt ja oftmals noch ein anderes Thema mit. Da würde mich auch interessieren, wie ihr das löst, nämlich der ganze Bereich der nicht-funktionalen Anforderungen. Wie ihr mit Usability-Anforderungen, die ihr wahrscheinlich an den Shop auch mithabt und an die App, wie ihr mit Security, Last and Performance, wie integriert ihr denn das in eure Teamstrukturen rein?
Ja, das sind unterschiedliche Themen. Das ist auf jeden Fall ein sehr wichtiges Thema. Wo fange ich an? Wir haben, fangen wir mal bei Security an, wir haben erstens bei uns im Bereich ein Team, was sich speziell um Security-Anforderungen und auch Services damit beschäftigt. Die bieten unter anderem erstmal so ganz einfache Sachen an, wie Security-Schulungen für alle. Die sind dann auch Pflicht, damit alle erstmal grundsätzlich das Know-how haben.
Zusätzlich nutzen wir bestimmte Tools, die wir von, also wir nutzen zum Beispiel von GitHub verschiedene Tools, sowas wie die PandaBot und sowas. Also genau, wir arbeiten alle über GitHub, unsere Repos liegen alle in GitHub. Deswegen haben wir von GitHub die Services eingekauft, die alle Teams dann auch verpflichtend nutzen müssen. Dann sind wir, unsere Infrastruktur
steht ja in der Amazon Cloud. Auch Amazon bietet verschiedene Tools an, die wir integriert haben, um automatisierte Scannings erstmal zu haben und uns eine Meldung zu geben, dass wir uns die angucken müssen. Und wir haben sowas ähnliches wie diesen Quality-Buddy, den ich schon gesprochen hatte, haben wir auch einen Security-Champion in den jeweiligen
Teams. Jedes Team hat jemanden, der wieder in so ein Austauschformat geht, der so ein bisschen die Security-Themen noch ein bisschen mehr betrachten soll und da Themen mit reinbringt. Genau, und dann gibt es eben gewisse Anforderungen, die wir einfach umsetzen müssen, die dann quasi von diesem Security-Team kommen, die sich den ganzen Tag mit Security in der Softwareentwicklung und drumherum beschäftigen. Das ist das Thema Security. Dann haben wir natürlich auch Dinge,
natürlich starke Last- und Performance-Anforderungen oder Verfügbarkeitsanforderungen. Also der Shop darf einfach nicht down sein, klar, dann wird es teuer. Also müssen wir dafür sorgen, dass er möglichst stabil ist und viel abkann. Auch dafür haben wir ein Team, die grundsätzlich erstmal übergreifende Last- und Performance-Tests ausführen, wo auch alle Teams sozusagen involviert sind. Die haben die entwickelt, diese Tests, und lassen die regelmäßig laufen
über alle unsere Umgebungen. Und wenn da was auffällt, gehen die halt auf die Teams zu und dann muss man da halt drüber sprechen und das optimieren. Und gemeinsam mit diesem Team haben die Teams dann auch Möglichkeiten, eigene Last-Tests zu konzipieren und zu schreiben und auszuführen. Genau, da kann man dann mit denen, weil die die Last-Test-Experten sozusagen sind, mit denen ins Barring gehen und da auch seine eigenen Services in den Teams
testen. Dann ist natürlich ganz wichtig so Alarming Monitoring, wo wieder jedes Team aber auch eigenverantwortlich unterwegs ist. Dann haben wir so Dinge wie Disaster Recovery ist uns noch ein wichtiges Thema. Da findet jedes Jahr, einmal im Jahr, ein Disaster Recovery Date statt, wo dann der Fall nachgestellt wird, ja, euer, keine Ahnung, AWS-Account
wurde komprimiert. Ihr müsst eigentlich von null anfangen und alles neu aufbauen. Und versucht das mal wirklich hochautomatisiert in Zusammenarbeit mit den anderen Teams, um Schnittstellen wiederherzustellen, zu machen und möglichst schnell. Das ist so die Grundanforderung
quasi. Und in diesen Disaster Recovery Days, damals hat das eben angefangen, dass das einmal im Jahr stattfand, können wir das halt einfach austesten und ausprobieren und sollen quasi das lernen, ja, wo fehlt's noch, wo müssen wir noch ansetzen, was müssen wir dafür
noch tun, um für den Ernstfall gewappnet zu sein. Und inzwischen ist es so, dass die einzelnen Teams dann regelmäßig selbst noch solche Tage durchführen, um den Prozess halt immer weiter zu optimieren und immer weiter, immer mehr auch automatisiert aufbauen zu können, damit das eben, wenn es mal passieren sollte, so ein Ernstfall, dass es halt sehr schnell geht. Genau, dann haben wir so übergreifende Ziele, wo ein bisschen vorausgeschaut wird
aufgrund von Analysen und so, wo müssen wir stehen in fünf Jahren meinetwegen. Was ist so die Erwartung, wie viele Produkte gibt's bei uns im Shop, wie viele Partner verkaufen über unseren Shop, wie viele Seitenaufrufe haben wir pro Sekunde, wie viele Kundinnen haben wir, aktive Kundinnen sind bei uns angemeldet und so was, um so eine gewisse Zahl als Ziel zu haben, worauf wir unsere zum Beispiel Last- und Performance-Tests auslegen müssen sozusagen.
Genau. Welches Thema habe ich jetzt noch vergessen, was du angesprochen hast? User-Based-Team war auch noch so ein Punkt. Genau.
Das ist für euch auch wichtig, ne? Das ist natürlich sehr wichtig. Also grundsätzlich sind in den Teams, die auch ein Frontend bereitstellen, egal ob jetzt in der App oder im Webshop, die haben erstmal UX-Leiter in ihrem Team, also UX-Designer*innen, UX-Manager*innen, die spezielle UX- und Usability-Anforderungen in die Teams halt tragen und da natürlich auch trotzdem so ein Oha haben, wie man das entsprechend zum Beispiel auch barrierefrei
macht oder so. Zusätzlich nutzen wir da auch ganz viel Kundinnen-Feedback, also wir machen regelmäßige Befragungen, wir arbeiten ganz viel mit A/B-Testing, wo wir eben Features oder so nur erstmal für einen Teil der Kundinnen bereitstellen und da schauen, wie die performen auch, aber auch wie eben das Feedback ist, wie die Kundinnen am Ende damit arbeiten können
sozusagen. Wir haben bei uns auf dem Campus hier in Hamburg, haben wir ein eigenes UX-Lab, wo wir tatsächlich dann echte Kundinnen einladen vor Ort, die spezielle zum Beispiel Features sich dann vom Bildschirm anschauen und getrackt werden quasi und dann eben direkt auch Feedback geben können, wie sie damit umgehen konnten, konnten sie das intuitiv bedienen beispielsweise und solche Dinge machen wir also ganz viel auch natürlich Kundinnen-Feedback einholen.
Ja, das ist natürlich für euch das A und O, wenn jemand, der sich nicht zurechtfindet auf so einen Shop, der ist ja so schnell weg, da kann man gar nicht schauen und geht zum großen A. Also das muss natürlich schon passen. So eine Frage, die ich noch habe, die mir schon oft dazu gebrannt ist, also mit meinem Lieblingsthema, wie sieht es denn bei euch so mit statischer Analyse aus? Unterschiedlich tatsächlich in den Teams. Das kann man gar nicht pauschalisieren. Es
gibt eben Teams, die nutzen das mehr, es gibt Teams, die nutzen das weniger. Zum Beispiel, also wir bei uns im Team, wir nutzen eben so Linting und sowas, aber speziell jetzt im Testkosmos nutzen wir das gar nicht so stark. Also wir haben gar keine Automatisierung,
wenn es darum geht, ja wir schauen uns unsere Testabdeckung oder sowas an. Sowas passiert dann eher lokal, dass ich, wenn ich selbst entwickle oder mit, wir entwickeln ja auch ganz viel im Pairing, dass wir uns da lokal mal sowas laufen lassen, wie sind wir da gerade
unterwegs oder dass ich zum Beispiel als QSler im Team mir sowas regelmäßig anschaue. Es gibt aber wie gesagt auch Teams, die tatsächlich in ihren CI/CD Pipelines da Quality Gates eingebaut haben, die sagen, okay, unsere Testabdeckung muss so und so hoch sein und da lassen wir dann auch tatsächlich automatisiert Analysen drüber laufen. Kann man gar nicht so pauschalisieren, da sind die Teams tatsächlich sehr autonom unterwegs.
Ja, spannend das auch in die Verantwortung der Teams zu geben, also das finde ich auch eine interessante Sache. Viele wollen das ja dann von außen auch steuern, wir müssen da jetzt unbedingt das alles ganz hart fahren, aber das in der eigenen Verantwortung zu lassen, das hat natürlich auch seinen Charme. Ja, ja.
Wenn du jetzt so auf die nächsten fünf Jahre schaust, also du hast ja vorher gesagt, das fand ich ganz schön, dein Ziel ist eigentlich, dich überflüssig zu machen in dem Team und dann zum nächsten zu ziehen, weil du das auch selber können solltest und dieses Wissen
und dieses Know-how selber aufbauen sollst. Wenn du jetzt so schaust auf eure Projektlandschaft und auf eure Teamlandschaft, was sind denn so die ein, zwei größten Brocken, die jetzt noch angegangen werden müssen, wo du sagst, das läuft noch nicht rund, da müssen wir noch besser werden?
Also die Herausforderungen, die wir vorhin schon als Thema hatten auf jeden Fall, sind eben diese, vor allem in ganz, ganz großen Projekten, die den kompletten Shop samt Backend und so betreffen, wo dann Bereichsgrenzen mehrfach überschritten werden, die Projekte auch End-to-End, End-to-End, Ende-zu-Ende testen zu können, mit möglichst wenig manuellem Aufwand, möglichst einfach, möglichst irgendwie im eigentlichen iterativen, agilen Prozess
integriert. Das ist so eine ganz große aktuelle Herausforderung, die uns sicherlich noch länger begleiten wird. Dann kommen natürlich so Themen wie KI, was ja in aller Munde ist, mit denen wir uns natürlich aktiv beschäftigen, mit denen wir ja auch schon ganz stark arbeiten, also bei uns wird schon ganz viel mit Algorithmen auch gearbeitet. Aber das Thema wird ja immer wichtiger, auch wie kann ich KI in meinen eigenen Arbeitsprozess einfach integrieren?
Genau, oder solche Dinge wie Co-Pilot oder so was, oder Ähnliches von GitHub, wie kann mich KI in meiner eigentlichen Programmierarbeit sozusagen unterstützen? Da geht es ja auch um beispielsweise, wie schreibe ich Tests? Also auch da kann mich die KI vermutlich unterstützen. Damit beschäftigen wir uns aktuell auch ganz stark und probieren da ganz viel aus und schauen da was zu finden, was irgendwie allen weiterhilft und Best Practices einzusammeln und so was.
Genau, dann geht es noch so um Dinge, wir sind ja nicht nur zukünftig im Webshop unterwegs und nicht nur in der App, sondern es wird ja immer mehr. Also man kann sich ja, zukünftig wird man, keine Ahnung, über eine Smart TV shoppen können, man wird vielleicht über das Auto shoppen können, keine Ahnung, was da noch alles an Möglichkeiten gibt und auch das muss natürlich irgendwie integriert werden und müssen wir ja quasi in unser System einbinden.
Darüber muss man auch, keine Ahnung, tracken können, darüber muss man andere Dinge tun können, die einfach technisch notwendig sind, das muss man auch testen können irgendwie. Solche Sachen, also ganz viele neue Technologien sind da die Herausforderung und eben die wachsende
Anzahl der Teams überhaupt, generell. Dadurch auch die Verminderung der eigentlichen QS-ler, weil es perspektivisch schon so sein wird, gehe ich zumindest persönlich erstmal davon aus, dass wir nicht mehr QS-ler werden, sondern dass schon das Zielbild ist eben, dass wir uns QS-ler nicht mehr brauchen, ich mache mich überflüssig und das komplette Team selbst kann die Aufgabe übernehmen, so wie wir uns das vorstellen sozusagen und lebt
Qualität halt von Anfang bis Ende mit und bearbeitet das mit und hat dieses Bewusstsein und das Know-how. Und dadurch wird es halt immer wichtiger, diese übergreifende Tätigkeit und eben das Thema übergreifen, teamübergreifend zu treiben, was wir eben jetzt schon machen,
aber das wird halt immer wichtiger. Also ich glaube nicht, dass ich dann in das nächste Team wandere, sondern ich glaube eher, dass ich von dem Team weg in diese übergreifende Tätigkeit wandere und meine Aufgabe wahrscheinlich dann eher darin liegt, weiter übergreifende Angebote zu schaffen, die Teams zu enablen und zu unterstützen.
Ja, super, es bleibt auf jeden Fall spannend. Ich werde mit einem Ohr und einem Auge immer wieder hinlucken, wie ihr euch weiterentwickelt und so, weil ich das, wie gesagt, auch ganz spannend finde. Ich arbeite mit vielen Konzernen zusammen und die Themen, die du angesprochen hast, da wäre ich froh, wenn manche schon da wären, aber es ist halt kein einfaches
Umfeld. Es gibt viele alte Strukturen, viele Themen, die nicht passen, Rahmenbedingungen, Infrastruktur, Organisatorisches, was bedacht werden muss, aber ihr seid da, finde ich, ein echt tolles Beispiel, dass das auch funktionieren kann, auch in diesen Größen. Vielleicht nicht nach Bilderbuch, aber zumindest fast. Das finde ich schon toll. Ja, ich danke dir herzlich, dass du hier in der Podcast-Folge mit dabei warst und uns nochmal diesen Einblick,
diesen Breiten gewährt hast. War vielleicht auch nicht das letzte Mal. Mal schauen, was dann in einiger Zeit noch für News kommen von euch, die wir dann natürlich hier auch bringen können. Ja, ich danke dir, dass du da warst und mir Rede-Antwort gestanden hast und wünsche dir noch viel Erfolg weiterhin mit deinen Teams und im Unternehmen und sag Dankeschön. Ja, vielen Dank. Ich bedanke mich auch. Hat sehr viel Spaß gemacht und
ja, genau, vielleicht hören wir uns ja mal wieder. War sehr spannend. Auf jeden Fall. Danke schön. Ciao. Alles klar. Mach's gut. Ciao. *Lachen*