Hallo und herzlich Willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Richie und mit Qualitätsleidenschaft hier auf der OOP 2024 in München für euch unterwegs. Bei mir gerade zu Gast Bastian Baumgartner, mit dem ich über das Thema Quality Coaching spreche. Was heißt das eigentlich? Was ist der Unterschied zur Beratung? Wie kann man es angehen? Was ist der Nutzen und warum ist das vielleicht auch für jeden mal interessanter
genauer hinzuschauen? Aber hört selber rein, viel Spaß bei der Folge. Hallo Basti, schön, dass du da bist. Hallo Richie, schön, dass ich da sein darf. Ja, finde ich super. Wir sind ja hier auf der OOP 2024 München. Hier laufen gerade die letzten in die nächste Keynote rein und wir machen hier unsere schöne Aufnahme. Zu einem Thema, was mir auch persönlich sehr am Herzen liegt. Darum habe ich gesagt, wir müssen uns
das unbedingt gönnen, auch für diese Folge hier. Und zwar geht es um das Thema Quality Coaching oder was macht ein Quality Coach und was ist das dann eigentlich? Weil das jetzt auch immer mehr auftaucht als Begriff. Im Gegensatz zum klassischen Testmanager, ich mache Testberatung und so. Das ist jetzt natürlich ein anderer Zugang und das ist schön, wenn wir das hier nochmal so ein bisschen reflektieren können und einfach darüber auch ein bisschen austauschen
können. Sehr gerne. Und da fange ich gleich mal an. Was heißt denn für dich Quality Coaching? Also Quality Coaching an sich bedeutet für mich, dass wir den Leuten, das sind teilweise so die Basics, dass wir, Testing for Non-Testers haben wir zum Beispiel, wo wir gewissen Rollen im Projekt
einfach ein bisschen mehr Einstieg Basics im Testing lernen. Das gehört für mich dazu. Aber auch mehr Qualität in die Prozesse reinzukriegen, wenn die gerade im Change sind, wenn sie agile Transformation machen zum Beispiel, was wir bei Kunden viel begleitet haben die letzten Jahre und dann häufig halt beobachtet haben, dass das Management hat zum Beispiel einen Quality Coach
bekommen, aber es wurde das Wissen nicht in die Mannschaft weitergetragen. Dann kommen wir, weil Probleme im Test entstehen, da werden dann die Berater angefordert und dann bist du halt sehr schnell in dieser Coaching-Rolle, weil du ihnen Methodiken zeigst, Sachen zeigst, die das Management vielleicht sogar kannte, die aber einfach in der Mannschaft nicht angekommen sind und du halt wirklich mit schönen kleinen Methodiken dann auch eine große Wirkung erzielen kannst.
Stichwort 3 Amigos zum Beispiel, das ist was, was mega wertvoll ist. Ja, kannst du das gleich mal erläutern, weil viele kennen das vielleicht gar nicht. Genau, also 3 Amigos ist im Prinzip eine Methodik, wo man sich, bevor man ins Refinement geht, um eine User Story dann im Team sozusagen zu diskutieren, sollte man sich zusammensetzen, gerade wenn es sehr große Storys oder sehr komplexe Storys sind,
und mit den drei Disziplinen drüber sprechen. Also 3 Amigos heißt ja nicht, dass man nur drei Leute
am Tisch hat, sondern da geht es um die drei Disziplinen. Man hat meistens einen PO oder ergänzt auch einen TPO zum Beispiel dabei, die dann eher so aus dem ganzen Anforderungserhebungen beziehungsweise Requirements Engineering kommen, dann die Entwickler und natürlich den Test und die sollten dann gemeinsam sich darüber abstimmen, wie kann diese User Story zum Beispiel umgesetzt werden bei der Entwicklung, wie können wir als Tester das Ganze dann auch testen und gerne auch
technisch und fachlich trennen zum Beispiel, was wir bei unseren Kunden relativ häufig haben, und dann hat man nicht mehr diese vielen Diskussionspunkte später im Refinement, weil einem klar ist, was mit der Story am Ende passieren soll beziehungsweise wodurch die Akzeptanzkriterien erreicht werden. Verstehe. Wenn wir jetzt so drauf schauen, was ist denn für dich so die prägnantesten Unterschiede, wenn man sagt, man macht einen Coaching-Ansatz im
Gegensatz zu einem klassischen Consultant-Berater? Was ich immer ein bisschen das Gefühl habe, also ich würde mich jetzt auch nicht als klassischen Consultant sehen. Natürlich so ein bisschen der Oberbegriff für unsere Berater-Tätigkeit ist immer Consultant. Ich habe aber schon oft das Gefühl, dass bei den großen oder dass viele Consultants, die haben so ein Schema F möchte ich nicht sagen, aber die haben einen gewissen Ansatz, den sie bei einer gewissen Opportunity
oder bei einer gewissen Stelle dann auch umsetzen. Ich glaube, beim Quality-Coaching ist es wirklich mehr so dieser Bottom-up-Ansatz. Wir machen viel mit Interviews zum Beispiel, um dann das Problem tatsächlich zu verstehen oder die Ursache des Problems zu verstehen und kommen da sehr nah an
die Mannschaft ran, die im Projekt arbeitet, bekommen da oft auch Informationen. Ich meine, da spielen Sachen mit, wie One Title Fits All hatten wir, dass auf einmal bei einem Kunden alle Testmanager und Testautomatisierer und Tester mit einem Titel zusammengefasst haben und da spielen dann echte Jobängste mit, weil sie nicht wissen, ob sie diesen Skills dann entsprechen. Und da habe ich manchmal das Gefühl, dass wir übers Coaching deutlich näher dran an
den Leuten sind und da auch viel mehr vom Mensch mitbekommen. Das finde ich eigentlich ganz schön, weil das ist meiner Welt auch nachhaltiger vom Ansatz her. Ja, ich glaube, es adressiert die Probleme. Ich denke da oft immer, wenn ich als Coach auftrete, die Lösung auch dort entstehen zu lassen im Team und quasi bei der Demo-Initiative kreativ werden zu werden und nicht quasi so für mich der klassische Berater, der dann so mit dem Fertigen
kommt. Das machen ja auch viele nicht mehr, aber so quasi einfach zu sagen, so macht man das. Jetzt also das Bild, was man im Kopf hat. Genau, sondern eher zu schauen, wie kann man das entstehen lassen im Team. Und ich finde immer, der größte Erfolg von dem Berater ist oder so, wie ich das sehe,
wenn sie uns nicht mehr brauchen. Also wenn wir es geschafft haben, diese Hilfe zur Selbsthilfe, dass wir unsere Kunden befähigt haben, die Methoden, die sie bei uns lernen, selber umzusetzen und uns am Ende nicht mehr brauchen. Ja, ja. Wenn du jetzt in so ein Team kommst und beginnst, also du hast jetzt quasi schon gesagt, drei Amigos ist sowieso ein paar. Was für Methodiken gibst du denen da noch rein, dass du quasi das aus dem Team auch heben kannst?
Genau, also was wir gerne machen, habe ich gerade gesagt, sind diese Interviews, weil uns das immer einen super Überblick gibt, wo der Schuh tatsächlich drückt, sage ich mal. Ja, du hast ja dann oft so ein bisschen den Eindruck vom Management. Also da kommt dann irgendwie die Anfrage, unsere IT und die Fachbereich redet nicht miteinander zum Beispiel. Und wenn du aber dann mit den Leuten redest, dann bekommst du die Problemstellung nochmal
ganz anders dargestellt. Wir schauen bei den Interviews normalerweise immer, dass wir die Ergebnisse anonymisieren, dann bilden wir Cluster draus und dann suchen wir uns so die Top 3 oder Top 5 raus und fangen mit denen erstmal an. Dann mache ich gerne so einen Discovery Workshop, nennt sich das. Da kommt es dann immer ein bisschen darauf an, wie die Organisationsstruktur beim
Kunden ist. Da gehen wir dann rein und machen entweder auch nochmal so eine Pains und Gains Ansatz, also dass quasi sie zum Beispiel die drei größten Pains im Testprozess gerade aufschreiben und die drei größten Handlungsfelder, also was würde ihnen am meisten helfen. Das lassen wir an die Wand wappen und mit Post-its und dann bilden wir da Cluster draus und können dann da
auch gezielte Gegenfolge machen. Dann habe ich gerne ein Riskstorming eigentlich immer gerne dabei, weil das total viel Sinn macht und mir dann auch eine gute Grundlage gibt, um zum Beispiel eine Teststrategie zu entwickeln, wenn sie eine brauchen. Wir haben aber auch schon Find-the-Bug-Sessions gemacht. Das ist so ein explorativer Test, den man gemeinsam macht, damit die Leute halt mal sehen, wie sowas funktionieren kann. Hier kann ich auch Testing-Touren einsetzen zum Beispiel. Also ich
versuche das immer auf die Bedürfnisse des Kunden sehr stark zuzuschneiden. Wir haben da einfach so einen Methodenkoffer, aus dem bedienen wir uns oder Testing for Non-Testers ist auch so ein Thema. Wir hatten zum Beispiel, mussten mal Scrum Master ein bisschen mehr Richtung Test-Impediments geschult werden und dann haben wir denen einfach mal so ein Grundrauschen im Testing beigetragen.
Wenn du jetzt so deine Projekte Revue passieren lässt, der letzten Jahre, Monate, hast du, siehst du da jetzt, so Paints, die er dann immer erfragt quasi auch oder quasi ermittelt über diese Methoden. Gibt es da so ein paar Klassiker, die immer wieder auftauchen? Also ich glaube, was immer ein Thema ist, sind Testumgebungen. Das ist auch wurscht, ob die CICD machen, ob die Water Scrum oder wie auch immer man es nennt, es ist wirklich egal. Da geht so viel
Zeit und Geld verloren. Das ist Wahnsinn. Wir haben ja diesen Testmaster bei uns, den wir auch als Ausbildung haben bei Quality Minds und da haben wir das tatsächlich, also das ist für mich ein Kapitel, weil ich das ganz wichtig finde. Ich habe da bei einem Kunden sehr gute Best Practices quasi erarbeitet mit den Kollegen zusammen, wie man Testumgebung oder Testumgebungen gut managen kann. Das zahlt er dann auch so ein bisschen ins Release Management
ein. Das ist ein Thema, das kommt immer. Was die letzten Jahre auch immer kommt, ist dieser Skill-Up von den Testern. Also wo sie alle Richtung Agilität gehen, wird bei einem agilen Tester erwartet, dass er gewisse Automatisierungs-Skills mitbringt. Das heißt ja nicht immer, dass die Leute dann direkt Java programmieren können müssen am Ende des Tages, sondern da kann man ja auch übers Toolset ganz gut steuern. Und das sind auch so Themen,
die eigentlich immer kommen. Ich habe in deinem Abstract noch gelesen, das hat mich total gefreut, auch dass in diesen ganzen agilen Methodenseiten, da sind ja immer Sachen drinnen, das waren Best Practices von anderen Unternehmen. Und auch darauf zu schauen, was ist denn eigentlich im Eigenen, also was kann man denn da eigentlich heben und wie kann man das adaptieren und nicht nur blind diese Dinge umzusetzen. Weil Best Practices der anderen sind halt Best Practices der anderen.
Wie bringst du diesen Gedanken so rein in die Unternehmen oder in die Teams auch, weil sehr häufig gesagt, wir müssen jetzt Scrum machen, wir müssen das so machen, weil das steht so irgendwo. Wie gehst du damit um? Also was ich das Schöne an der Agilität finde, ist ja, dass jeder so ein bisschen Gestaltungsspielraum hat. Und ich habe noch nie irgendwo erlebt, dass mal jemand Scrum oder Scrum
of Scrums oder Less oder Save nach Lehrbuch gemacht hat. Das wird immer adaptiert. Spotify Modell hat bei Spotify auch nur bis zu einem gewissen Zeitpunkt funktioniert, dann sind sie zu groß geworden. Dann ist das auch nicht mehr so gut gelaufen. Und ich meine, da steht der Name von Ihnen drauf. Und ich finde halt, das Schöne, was wir haben, ist, dass wir die Möglichkeit haben,
das so zu gestalten, dass es zu den Kunden passt und zu den Problemen passt. Und was ich immer versuche zu sagen, ist, das Schöne an der Agilität ist, ihr könnt euch die guten Teile rauspicken und das benutzen, aber es heißt nicht, dass ihr das eins zu eins so umsetzen müsst. Und ich glaube wirklich, ich habe es noch nie erlebt, dass irgendwer zu 100 Prozent nach Lehrbuch vorgegangen ist. Meistens eine Adaptierung, aber oft will man es nicht wahrhaben. Also nein, wir machen Scrum.
Aber nein, eigentlich doch nicht. Aber das ist ja bei den Methoden eigentlich auch egal. Also das Framework, was dahinter klemmt, spielt ja im ersten Moment noch keine Rolle. Es geht ja darum, den Leuten zu helfen, ihre Probleme zu beseitigen und ob das dann im Less oder im Safe gemacht wird. Also das ist das Einzige, was mich bei diesen Scale-Themen ein bisschen stört, ist, dass da
der Test komplett außen vor ist. Aber das ist, glaube ich, eher ein persönliches Ding. Aber ansonsten, glaube ich, ist das Schöne daran, dass wir die Möglichkeit haben, das frei zu gestalten. Wenn du jetzt als Quality-Coach ins Team kommst oder da mitwirkst, was sind denn da so für dich die größten Herausforderungen, mit denen du dealen musst? Also zum einen komme ich selten als Quality-Coach direkt ins Team. Das ist meistens was,
was sich dann mit der Zeit ergibt. Wir werden oft als, keine Ahnung, Testmanager für einen End-to-End-Test oder ich war Interims-QA-Lead bei einem Unternehmen, solche Sachen. Darüber komme ich rein. Was, glaube ich, die größte Herausforderung ist, die wir immer haben, ist der Mindset-Challenge. Gerade wenn du mit Unternehmen zu tun hast, die viel mit so Hierarchien sehr klare Strukturen gearbeitet haben. Und dann ist die Erwartungshaltung, man schwingt von einem aufs andere Jahr in die
agile Softwareentwicklung um und die Mitarbeiter ziehen alle mit. Das muss halt auch entsprechend unterstützt werden. Und wir haben schon gelernt oder festgestellt für uns, dass so Communities of Practice zum Beispiel das war, wo du bei den Leuten dann auch wirklich beobachten kannst,
wie sich das Mindset dann ändert. Aber das dauert einfach manchmal ein bisschen. Ich meine, die Leute haben teilweise 15, 20 Jahre in dieser Unternehmung, in dieser Organisation gearbeitet und dann finde ich die Erwartungshaltung, dass sie innerhalb von einem auf einen anderen Monat oder Geschäftsjahreswechsel dann umschwingen und ein komplett anderes Mindset, gerade dieses selbstorganisierte. Ich hole mir meine Aufgaben selber. Da haben viele Tester Schwierigkeiten.
Die hatten jahrelang Testmanager, die ihnen die Tickets vorm Sprint quasi zugeschoben haben. Und jetzt sollen sie sich hinsetzen und sollen sich die Aufgaben selbstständig holen und Eigenverantwortung übernehmen. Da tun sich viele halt einfach schwer. Du hast gerade Community of Practice genannt. Kannst du das noch erläutern? Weil ich glaube, nicht jeder hat da so ein Bild davon. Genau, also in der Idealwelt heißt es ja, dass eine Community of Practice sollte sich
eigentlich selber leiten, sollte sich selber organisieren. Das ist eigentlich ein schon organisierter Zusammenschluss zu bestimmten Themengebieten. Also wir haben bei Kunden zum Beispiel eine Community of Practice für Tester ins Leben gerufen. Wir haben dann davor immer abgestimmt, was für Themen wollte da besprechen. Da geht es auch so ein bisschen um Erfahrungsaustausch in großen Organisationen. Wenn zum Beispiel in einem Team ein besonders neues Tool verwendet
wird, dann hat das mal einer der Kollegen vorgestellt. Oder wenn sie eine neue Methodik gelernt haben und die bei sich gut einsetzen konnten, hat man die vorgestellt, um halt so dieses Voneinander-Lernen auch ein bisschen zu fordern. Wir nutzen das bei QM intern auch bei uns bei Quality Minds und machen da mit unseren Testern zum Beispiel haben wir alle zwei Wochen Let's Test nennt sich das, wo dann genau auch dieses Thema dahinter steht, was halt immer
selbst organisiert sein sollte. Man merkt aber schon, wenn man das Thema neu etabliert irgendwo, da braucht es so einen Moderator oder einen Community Manager oder Managerin, die sich da drum kümmert, das Ganze ein bisschen ins Leben ruft, die Leute anleitet und sich
einfach dahinter steht, bis das dann selber ins Laufen kommt. Wahrscheinlich auch gerade, wenn jetzt Kunden oder so aus der alten Welt kommen, wo das einfach noch ungewohnt ist oder wie du sagst, Tester war immer gewohnt, dann ist man ja da meistens auch nicht so engagiert oder selbst organisiert, dass man sich das traut oder weiß, was man tun soll. Und da braucht es halt einfach ein bisschen Klarheit am Anfang und dann den richtigen Stups in die
richtige Richtung. Manchmal braucht es auch Freigaben von Vorgesetzten. Das erleben wir tatsächlich auch in Unternehmen, wo halt dann die Hierarchien noch sehr vertreten sind, trotz der Agilität, dass sie halt diese Dreiviertelstunde dann alle zwei Wochen irgendwie investieren dürfen. Würdest du jetzt, wenn jetzt jemand zuhört, sagt, ach, coole Sache, Community of Practice, die Tester, das könnten wir bei uns auch machen. Zwei Wochen ist so ein
Rhythmus, wo du sagst, das passt? Das kommt darauf an, wie lange man es macht und auch, wie viele Teilnehmer man hat. Wir haben jetzt bei uns dann auch die Community of Practice zum Beispiel dann zum Thema Testautomatisierung abgespalten, weil da einfach die Interessensgebiete zu weit auseinander waren. Und dann kann es auch mal sein, dass es zwei oder drei Communities
of Practice dann in dem Ablauf sind. Ich glaube, zwei Wochen ist ein ganz guter Turnus, weil man dann auch Zeit hat, sich darauf vorzubereiten oder das eben aus der Community rauszusteuern, dass dann tatsächlich was passiert in der Community. Und manchmal muss man ja zu einem Thema noch mal ein bisschen Recherche betreiben oder mal Vergleiche ziehen. Und ich glaube, zwei Wochen ist eigentlich ein ganz guter Turnus.
Ja, ja. Jetzt ist ja Qualität, Quality Coaching ist ja schon im Namen drin, da geht es ja um Qualität und nicht mehr nur um Testen, wenn man Testen als Teil davon sieht. Also das ist ja auch etwas, Qualität ist Gesamtverantwortung vom Team und so, und da gibt es natürlich ganz viele Protagonisten, Entwickler, Architekten, Anforderer, inwieweit nimmst du denn das mit auf oder wie integrierst du das, dass da nicht nur mit den Testern rumspielt, sondern auch das gesamte Team da mit dabei hat?
Es war uns ja schon oft, oder was ich finde, was wir oft erleben, ist ja, der Test ist ja immer das Ende der Nahrungskette. Das heißt, in diesem ganzen Softwareentwicklungsprozess kommen wir Tester immer am Schluss. Wenn wir jetzt über drei Amigos reden,
habe ich die anderen Disziplinen sowieso dabei. Wenn es aber darum geht jetzt zum Beispiel auch, dass die Entwickler, also ich mache auch gerne zum Beispiel so Mob-Testing-Sessions, das ist was, wo dann, da mache ich gerne so Driver-Navigator-Ansatz, habe dann vorne eine Person sitzen und wir haben das ganze Team am Tisch und jeder darf zwei Minuten sagen,
wie der andere vorne testen soll. Und dann lernen die anderen dann voneinander, ja schau mal, der Kollege aus der Entwicklung geht da so ran und der Softwarearchitekt geht da so ran und dadurch ist dieser Wissensaustausch im Team da und ich habe einfach alle mit abgeholt. Ich meine, Qualität ist immer Ergebnis des Gesamtprozesses. Das ist nichts, wir können ja keine Qualität irgendwo rein testen. Das funktioniert ja nicht. Und insofern versuche ich die schon immer alle
mit abzuhören. Und auch diese Schwarmintelligenz zu nutzen, die sie im Team haben und das voneinander lernen, voneinander profitieren, das ist ja dieser Whole-Team-Approach, den wir einfach leben müssen, glaube ich, in der Agilität. Und hast du damit noch heutzutage mit Ressentiments zu tun, dass der Entwickler dann sagt, ach komm, lass mich mit diesem Testkram zurück oder der Architekt sagt, nee, ich bin hier die Koryphäe und ich sage eh, wo die Technik lang geht,
ich brauche mich um so Qualität gar nicht kümmern oder gibt es das noch? Und wenn ja, wie gehst du damit um? Also ich habe das bei den, eher so Richtung Product Ownership und Business-Analyse oft erlebt, wobei man da auch, wenn man dann den Mehrwert zeigen kann, also es war auch bei einem Kunden, wo ich die 3 Amigo-Session etabliert habe und wo der dann gesagt hat, Maja, sollst du noch eine Dreiviertelstunde investieren, wir haben ja eh
schon Refinement und so weiter. Aber wie sie dann halt nach einer gewissen Zeit gesehen haben, wie viel schneller sie dann im Refinement sind und auch alle Stories geschätzt bekommen und einfach fertig werden, dann muss man halt manchmal erst mal zeigen, dass man da wirklich Mehrwert generiert, auch wenn es im ersten Schritt ein Meeting mehr ist. Ansonsten geht es eigentlich, muss ich ganz ehrlich sagen. Also gerade dieses, ich finde, dass wir durch die Agilität sind,
Entwickler und Tester näher zusammengekommen. Da fand ich früher den Graben dazwischen irgendwie größer. Das ist, finde ich, ist deutlich besser geworden und das sehen ja auch die Entwickler den Mehrwert davon, wenn die Tester quasi technisch sich ein bisschen einen Skill-Up haben und da ihnen vielleicht auch Tests abnehmen oder auf ihren Tests aufsetzen oder sie voneinander mit der Automatisierung lernen können. Also ich glaube, die Synergieeffekte sind einfach größer und das
finde ich. Und dann gibt es ja auch, ich meine, es gibt ja auch Kunden, die das dann so leben, dass es die Rolle an sich gar nicht gibt und derjenige macht das, wo er gerade Zeit dazu hat und dann ist eh wurscht, ob der Entwickler, Tester, Testautomatisierer oder was auch immer. Das funktioniert aber auch sehr gut. Ja, ich glaube auch, dass die Professionen da einfach viel mehr zusammenkommen und dass das mittlerweile auch angekommen ist, dass es das auch einfach braucht,
um guten Output dann auch zu liefern und gut miteinander arbeiten zu können. Wenn du so auf den Softwareentwicklungsprozess schaust und da so drin bist, aus Qualitätssicht heraus, wo siehst du denn noch das meiste Potenzial, wo wir so quasi in Unternehmen oder in Teams noch am meisten heben können? Also was aus meiner Sicht, glaube ich, so der nächste große Peak wird, ist ja in aller Munde ist das ganze Thema KI oder AI. Und da scheiden sich ja im Moment noch so ein bisschen
die Geister, ob wir darüber reden, wir testen mit KI oder wir testen KI. Ich glaube auch, dass das Thema, das ist aber vielleicht auch ein bisschen der Bubble, wo ich mich bewege, aber End-to-End-Testing ist auch so ein Thema. Also gerade wenn du Unternehmen hast, die sehr viel Fachspezifika in den Testfällen brauchen, hast du halt oft Leute aus der
Fachabteilung, die mittesten und die machen sehr viel UI-Getrieben im End-to-End dann. Und das sind natürlich, da werden Ressourcen gebunden, das sind ewig lange Testaktivitäten, Staffelstabübergabe funktioniert dann an den Schnittstellen immer so mittelprächtig. Da kann es dann auch mal sein, dass du zwei Tage Pause machen musst, weil wir irgendein Problem entdeckt haben, dann machst du weiter. Das muss ja gut organisiert werden. Aber ich glaube, das KI,
das wird unsere Arbeitswelt nochmal verändern. Also ich glaube, dass wir da auch als Tester jetzt gefordert sind oder auch so als Quality-Coaches, da uns Methodiken zu überlegen. Und dann halt auch für die Bereiche testen wir KI und testen wir mit KI. Also das sind so zwei Welten. Und ich glaube, da sind aktuell einige dran, da was zu machen. Aber ich glaube, dass
das so der nächste große Peak bei uns im Bereich wird. Hat man hier im Podcast ja auch schon ein paar Mal das Thema, das kommt auch immer wieder raus, dass einfach der Zugang auch ein anderer wird. Also früher als Tester das alles deterministisch und ich habe diese Qualitätskriterien gegen dich geprüft. Das sind zwei Dinge, die einfach sich ändern. Die Qualitätskriterien werden andere und da muss ich einfach auch einen anderen Blick drauf haben. Aber das werden wir auch
schaffen. Das ist ja das Spannende an uns. Das ist auch das, was ich an der Beratung mag. Es wird nicht langweilig. Wir haben immer neue Themen. Und ich finde, das andere, was du gesagt hast, auch total naheliegend. Das ist ja etwas, was ich bei meinen Kunden häufig beobachte. Solange ich in meinem Umfeld bleibe, in meinem Projekt, in meiner Applikation, bei meinen Services, da habe ich immer alles so gut im Griff. Aber sobald es dann rausgeht in Richtung End-to-End
oder Systemintegration, da beginnt immer so ein bisschen eine Unklarheit und ein Gerangel. Und wer macht was und wer kümmert sich denn eigentlich und wer organisiert das? Dann gibt es ein eigenes End-to-End-Team. Das ist wieder viel zu weit weg von den Einzelthemen. Und da gibt es viel, was, glaube ich, noch besser werden kann. Ja, und auch dieses Konfliktpotenzial, was man da auf der einen Seite hat. Und ich glaube aber auf der anderen Seite auch,
es gibt sehr viele Tools, die End-to-End-Tests unterstützen. Aber es gibt eigentlich jetzt keine so richtige Methodik, wo du sagst, da kannst du mit Best Practices drauf aufsetzen. Und das, glaube ich, da ist einfach an der Zeit. Und dann hast du ja auch immer mehr Unternehmen, die Software produzieren, um eigentlich irgendein Produkt zu produzieren. Also die jetzt gar nicht aus der Softwareentwicklung kommen, die ja dann meistens noch hemmsärmeliger unterwegs sind,
wie irgendwelche anderen. Und für die steht das auch nicht im Fokus. Aber die Software muss trotzdem funktionieren am Ende des Tages, weil sie halt, keine Ahnung, ein Auto bauen wollen am Schluss. Und da ist es dann von der Herausforderung nochmal eine andere. Und die
sind auch immer sehr stark in diesem End-to-End-Test. Ja, super. Basti, vielen lieben Dank für diese Einblicke, Ausblicke und ein paar Ideen und Inspirationen, auch wie man sowas umsetzen kann, wie man sich dem ganzen Thema auch nähern kann, welche Methodiken man nutzen kann. Finde ich super spannend. Und ich glaube, da hat sich ja der eine oder andere eine Idee jetzt auch mitgenommen. Ich danke dir schön, dass du hier Rede und Antwort gestanden hast. Und ich wünsche
dir noch ganz viel Spaß hier auf der OOP. Danke. Vielen Dank.