Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute wieder mit einer Folge von der OOP 2024 in München. Bei mir zu Gast waren gerade Annika Strake und Benedikt Breuch von der Firma Appmatics. Sie berichten uns von einem spannenden Testautomatisierungsprojekt beim ZDF, wobei Testautomatisierung vielleicht nicht so ganz richtig war, aber es geht gar nicht nur um Testautomatisierung, sondern um eine schlaue Kombination zwischen manuellen und automatisierten Tests.
Aber hört selbst, viel Spaß bei der Folge. Hallo Annika, hallo Bene, schön, dass ihr da seid. Hi. Hallo. Freut mich, ihr seid hier auf der OOP, eine der ersten Podcast-Gäste hier in dem mobilen Studio. Und ja, es freut mich, dass sie es geschafft haben, dass wir einen Termin gefunden haben, wo es passt. Und ich habe so im Vorfeld die Abstracts ein bisschen durchgelesen und bei euch bin ich dann so hängen geblieben.
Zum einen, weil ihr ein spannendes Kundenprojekt habt und dann da auch ganz schön Handling zu tun. Auch das hat man so rausgelesen mit Testautomatisierung, wie kann das alles sein? Und ja, deswegen wollte ich euch unbedingt einen Podcast haben, damit wir über eure Erfahrungen da mal sprechen können. Und ich würde gleich mal so rein starten. Was war denn, ihr habt ja auch den Vortrag dazu hier gehabt, was ist denn da so der Rahmen, der da eure Erfahrung begleitet?
Ja, erstmal cool, dass wir die Chance bekommen, auch hier mit dir sprechen zu können. Ja, vielleicht einmal so, um ein bisschen den Bogen zu spannen. Wir haben bei der Ausschreibung vom ZDF mitgemacht, weil die Idee war, einfach für alle Apps, die die so rausbringen, Qualitätssicherung zu machen. Das Thema war bisher so ein bisschen stiefmütterlich behandelt und da sollte einfach das nächste Level Einzug halten.
Und da ist natürlich, wie es jetzt bei den meisten Entscheidern und Managern so gegangen gäbe, ist Automatisierung so das Ziel. Also in der Ausschreibung stand dann drin, dass alles automatisiert werden soll, also auch nur automatisiertes Testing angeboten wird. Und wir haben dann die Ausschreibung gewonnen und dann einen etwas anderen Ansatz gewählt. Annika, vielleicht möchtest du da irgendwie ein, zwei Sätze zu sagen. Ja, genau.
Also das ZDF hat natürlich die größte Herausforderung, dass sie besonders viele Geräte abdecken müssen. Auch besonders alte Geräte, um einfach das für alle zugänglich zu machen. Und das ist natürlich, man kann vieles automatisieren, auch viel auf den Endgeräten automatisieren. Aber das stellt eine große Herausforderung dar. Also gerade unterschiedliche OS-Versionen, unterschiedliche Androids, auch Android-Versionen sozusagen, wenn dann noch Samsung ihr eigenes da drüber baut und so.
Das ist dann automatisiert sehr, sehr wartungsaufwendig, weil man eben tausend Sonderfälle irgendwie abfangen muss. Und dann muss man halt eine gute Abwägung darin finden, was automatisiere ich und auch wie viele Geräte und was will ich da eigentlich alles abbilden. Und wie kann ich sozusagen diesen Gap dann schließen? Und das haben wir dann versucht, oder das machen wir jetzt, indem wir das dann zusätzlich eben auch manuell testen. Und da dann auch noch mehr Geräte.
Also wir haben so ein Grund-Setup von 15 bis 20 Geräten in der Testautomatisierung, was schon auch relativ viel ist. Aber klar, man möchte natürlich auch eine gewisse Bandbreite abdecken. Aber dann holen wir eben auch noch mehr Geräte dann manuell dazu.
Und gerade auch, wenn wir versuchen, dann die Fehler einzugrenzen, die sich vielleicht auch aus den automatisierten Tests dann ergeben, ist das natürlich manuell dann viel, viel schneller, als wenn man versucht, alle automatisierten Tests zu durchforsten und zu gucken, woran könnte es denn jetzt gelegen. Und wenn wir dann auch noch mehr Geräte abdecken, ist das dann in der Regel dann manuell dann doch schneller, wenn man schon so eine Vermutung hat.
Ich weiß nicht, es könnte daran liegen, dass Android 9 oder so nicht, dass der Fehler nur da auftritt. Dann nehme ich mir halt noch ein paar Geräte, gucke, ob es klappt oder nicht. Und das ist dann halt genau, das ist so ein bisschen der Ansatz, den wir da aktuell fahren, dass wir eben einfach so ein bisschen zweigleisig fahren. Und auch eben so ein bisschen versuchen, die Testabdeckung dadurch zu stärken oder zu erhöhen.
Dadurch, dass man durch die Automatisierung natürlich... ...durch die Automatisierung natürlich sehr viele, ja in sehr viele kleine Ecken sozusagen reingehen kann. Also ich kann natürlich auf jede Sendung klicken und auf jeder Sendungsseite dann mir angucken, okay, ist da alles vorhanden? Führen die Links zu auch bestimmten Sachen und so weiter? Wenn ich das manuell machen würde, würde das sehr, sehr lange dauern.
Und auf der anderen Seite haben wir natürlich Sachen, die wir automatisiert nicht so richtig gut testen können, wo auch vielleicht Visibility eine Rolle spielt, die das in einem manuellen Testing, ja, die das einfach besser machen können und dann auch explorativ da... ...andere Fehler finden einfach. Verstehe. Es ist ja ein bisschen anders, als man sich das so vorstellt. Weil wenn man, wenn ich als Manager denke, ja super, da kann ich ja dann alles automatisieren.
Das war ja auch der Auftrag an euch. Aber was waren denn so wirklich die Beweggründe zu sagen, nee, so geht das nicht? Und vor allem, wie habt ihr das dann auch dem Kunden vermittelt? Der wollte ja was anderes. Ja, also im Endeffekt hat sich das fast automatisch ergeben, weil die... ...Software, die die Entwickler bisher geliefert haben, gar nicht sich so gut geeignet hat für die Automatisierung.
Also da waren Tags und IDs zum Teil nicht gesetzt, die es deutlich einfacher machen, um das zu automatisieren. Und gerade wenn die App konstant weiterentwickelt wird, ist die Wartung dann eben auch aufwendiger. Und je einfacher das von den Voraussetzungen her ist, desto einfacher natürlich dann auch konstant mit Automatisierung zu unterstützen. Dadurch hat sich das Onboarding oder die Kick-Off-Phase relativ lange gezogen.
Und wir haben das auch so gemacht, dass wir das dann auch konstant mit Automatisierung unterstützen. Wir haben dann einfach gesagt, hey, ihr wollt ja im Endeffekt sehr regelmäßige Tests und sehr regelmäßige Ergebnisse. Dann starten wir jetzt einfach manuell und irgendwann kommt die Automatisierung dazu. Und in dem Zuge haben wir halt gemerkt, ja okay, da sind Cases dabei, die hätten wir über die Automatisierung überhaupt nicht abgebildet.
Weil da müssen wir uns natürlich auch aus Kosten und Zeitgründen auf einen gewissen Rahmen einigen. Und dadurch, dass wir aber diesen manuellen Teil immer dazu haben, können wir einfach ganz viele Cases noch mit abtesten, die entweder zu aufwendig wären, um die zu automatisieren. Oder die so nischig sind, dass man die in der Automatisierung eh niemals abbilden würde.
Und darüber haben wir halt so ein bisschen, ja, also Hauptargument war dann auch, dass wir dadurch mehr Flexibilität gewinnen, wenn wir uns nicht nur auf automatisierte Tests beschränken. Auch wenn kurzfristig Änderungen kommen, wenn Hotfix-Releases gefahren werden müssen. Da haben wir einfach diesen manuellen Teil in der Hinterhand, der einfach viel, viel besser zu dem passt, was auch tagtäglich in so Softwareentwicklungen passieren. Da kommt eine neue Deadline.
Da kommt eine Management-Entscheidung. Das muss jetzt noch bis dann rein. Und so schnell kann Automatisierung in der Regel halt nicht reagieren. Ja. Wie evaluiert ihr denn, ob jetzt ein Testfall automatisiert werden kann oder ob manuell? Weil das je nachdem, wie komplex er ist, aber wie? Irgendwann müsst ihr ja diese Entscheidung treffen.
Genau. Also wir schauen uns einerseits an, ob es bestimmte Fälle gibt, die eben besonders, wo zum Beispiel die Testabdeckung dadurch erhöht wird, wie ich es gerade beschrieben habe. Ja. Und dann ist es natürlich etwas, wo wir sagen: Okay, das darf halt auf gar keinen Fall kaputtgehen. Alles, was so Key-Features sind und die Happy Paths und so weiter.
Und das merkt man dann auch schnell, auch wenn man selber manuell testet, dass man so merkt: Okay, das ist irgendwie sehr, sehr müßig, das zu machen. Warum kann man das nicht automatisieren? Dann hat man schon mal auch schon ein erstes Indikator. Deswegen ist es eigentlich auch gar nicht so schlecht, eben manuell direkt anzufangen, weil man eben auch ein Gefühl dafür bekommt.
Auch wenn man eine App ein-, zweimal, dreimal testet, kriegt man ja auch schon wieder ein anderes Gefühl einfach für die App und auch für die Probleme, die da so regelmäßig auftauchen. Und das sind natürlich auch Indikatoren. Also wir merken: Okay, an bestimmten Ständen treten häufiger Probleme auf. Dann sind das vielleicht auch Testfälle, die wir automatisieren. Ah ja. Jetzt ist ja so eine Automatisierung von so Apps. Also da gibt es ja total viele Ausprägungen und so was.
Wie ist denn da so euer Blick darauf? Wie stabil läuft denn das Ganze so? Oder habt ihr auch so Betriebsverfahren? Betriebssystemprobleme, Infrastruktur, Dinge, wo dann Dinge weg einfach nicht funktionieren? Weil sie halt einfach nicht funktionieren gerade. Ja. Die Antwort ist ja. Also wir haben, also gerade in der Automatisierung kommt es natürlich sehr darauf an, wie doll das Frontend angefasst wurde. Also wie sehr man vielleicht auch in den Tests ein bisschen fixen oder anpassen muss.
Aber wir haben zum Beispiel auch gerade aktuell das Spielen. Und bei der Testautomatisierung so viele Software-Elemente oder so viele unterschiedliche Anbieter eine Rolle, die man alle irgendwie zusammenbringen muss. Und dann gibt es ein Update für iOS und schon funktioniert dann aber das Tool, wo man automatisiert nicht mehr mit dem neuen iOS und so. Das haben wir schon auch die Probleme.
Die können wir dann Gott sei Dank manuell immer dann noch abfangen, wenn wir dann merken: Okay, wir haben zum Beispiel eine iOS-Version, die wir aktuell nicht automatisiert testen können. Die können wir dann manuell trotzdem testen. Und dann können wir dann auch trotzdem mitnehmen. Und aber das Gute ist sozusagen, also dieser, der, das Setup-Aufwand ist relativ hoch, aber danach der Wartungsaufwand ist dann im Rahmen, würde ich sagen.
Also wir, innerhalb eines Tages können wir dann auch alle Fehler, die da so auf Automatisierungsseite anfallen, fixen. Und wir sind, also es sind auch gar nicht mal so viele. Also von den Failed-Test-Cases sind ungefähr 90 Prozent auch tatsächliche Bugs dann in der Software und so 10 Prozent. Ungefähr dann Fehler, die halt in der Automatisierung passiert sind. Das kann natürlich ganz unterschiedlich sein.
Einfach, dass ja, dass, dass die Software dafür abgestürzt ist zum Beispiel, kann auch mal sein. Oder aber auch, dass vielleicht im Test-Case was verändert hat oder die Software was verändert hat, dass wir halt automatisiert jetzt dann nicht mehr abdecken können. Ja, ja. Führt ihr die Ergebnisse dann auch zusammen von eurem manuellen und automatisierten Test? Wie macht ihr das? Ja, also tatsächlich werfen wir quasi in unserem eigenen Tool Testmatics.
Die. Also die Ergebnisse der Automatisierung aus. Und dann guckt ein Testanalyst von uns drüber, der dann quasi auch die Aufgabe hat, das manuell zu verifizieren. Also der schaut dann in die Ergebnisse rein, nimmt so eine erste Einschätzung vor. Ist das wahrscheinlich ein Fehler in der Automatisierung oder eben in der App? Und der holt sich dann Tester dazu oder macht selber, dass er sich Geräte schnappt und dann versucht, das manuell nachzustellen und eben dann darüber auch einzugrenzen.
Tritt das nur bei iOS, nur bei Android auf, auf bestimmten OS-Versionen? Ist es vielleicht auch ein visueller Fehler, der mit der Screensize zusammenhängt? Ist das ein Tablet-Problem? Das sind alles Sachen, die gerade bei sowas wie, nehmen wir mal die ZDF-Mediathek, natürlich eine große Rolle spielen.
Wenn da irgendwas nicht richtig angezeigt wird, wenn der Vollbildmodus nicht richtig skaliert, das sind alles so Sachen, die sind auch sehr, sehr schwierig über die Automatisierung allein zu finden. Ja. Wie ist denn so die Abdeckung? Also, oder sagen wir mal die Relation, ihr habt ja quasi manuell begonnen mit Testautomatisierung. Wie ist sie generell und bleibt die stabil?
Oder merkt ihr, da gibt es einen Trend mehr zur Automatisierung oder doch mehr zu manuellen Tests, weil es durch die Komplexität manchmal wichtiger, einfacher ist? Ja, also im Endeffekt ist es so, dass wir jetzt glaube ich gerade bei so 70, 80 Prozent automatisierten Cases sind. Aber wir haben eigentlich auch kein Interesse daran, dass wir jetzt die manuellen Tests irgendwie runterfahren.
Weil wir da doch im explorativen Testing immer wieder auch Sachen finden, die dann auch für die Automatisierung relevant sind. Also der Anteil wird höher dadurch, dass wir noch mehr automatisieren.
Also wir können automatisierte Cases dazunehmen, aber nicht dadurch, dass wir dann manuell wirklich auch weiter reduzieren, sondern alles, was wir an Kapazitäten gewinnen, dadurch, dass die Automatisierung aufgeschlossen hat, stecken wir dann wieder in die manuellen Tests, dass wir irgendwie Testcases granularer anlegen, dass wir mehr explorativ testen, mehr Geräte dazunehmen. Also dass wir da quasi immer auch eine Weiterentwicklung haben und immer besser werden.
Weil sonst wäre es so ein bisschen hin und herschieben von Ressourcen. Ja, okay, jetzt haben wir wieder was automatisiert, dann nehmen wir was aus dem manuellen Testing weg. So funktioniert es nur ganz am Anfang. Wenn wir halt wirklich rein manuell starten und dann teilweise immer weiter auch manuelle Tests durch automatisierte ersetzen. Aber ab einem gewissen Punkt sagen wir dann, ja okay, das ist schon das Maß, was wir noch als Unterstützung immer dabei haben.
Und wie habt ihr denn diesen Feedback-Mechanismus implementiert, wenn ihr also manuell explorativ testet und da kommt es raus, ah, das könnte was für Automatisierung sein. Macht ihr das zyklisch oder wie ist das so bei euch integriert in den Prozess? Genau, also wir testen einmal die Woche, regelmäßig auf jeden Fall und sonst nochmal auf Zuruf. Und bei uns sind alle Tester vor Ort auch.
Das bedeutet also, wir sind ja kein Crowdtest-Anbieter, sondern bei uns wird alles vor Ort, die Leute sind fest angestellt, wird vor Ort getestet und dann sind die Wege auch nicht so weit. Dann gibt man da kurz Feedback oder stellt das in ein Ticketsystem ein. Das wäre echt eine gute Idee, wir das zu automatisieren. Dann wird das nochmal gereviewt und dann wird es gemacht oder nicht. Genau. Ja, und ich würde sagen, das Hauptargument ist halt die Kritikalität.
Also wenn wir explorativ was finden, was unsere Testfälle nicht abdecken, was aber eigentlich kritisch oder ein Blocking-Ticket ist, wo wir sagen würden, so kann das Release gar nicht rausgehen. Das sind halt Sachen, wo wir dann genau schauen, ist das ein Fall, der wieder auftreten kann? Ist das nicht was, was wir immer mit abtesten sollten, damit sowas halt nicht durchgehen kann?
Also ja, ich glaube, Kritikalität ist eigentlich das Hauptargument zu sagen, da machen wir jetzt noch einen zusätzlichen Case für. Oder auch häufig. Also wenn wir merken, in einem bestimmten Bereich, den wir jetzt automatisiert noch nicht so abgedeckt haben, weil er vielleicht auch nicht so zu den absoluten Hauptfeaturen gehört, wenn da immer wieder ähnliche Fehler auftreten und so, dann macht es natürlich schon Sinn, den auch mit automatisiert abzulegen. Ja, ja, ja.
Das heißt, also wenn ich es richtig verstanden habe, wenn es ein Explorativ und da kommt raus, das ist was, was man generell testen sollte, dann habt ihr ja immer noch die Weiche, das manuell strukturiert zu testen oder automatisiert dann umzusetzen. Ja, also wahrscheinlich würden wir dann so... Also... In der ersten Woche fällt der Fehler auf, der ist dann kritisch. In der zweiten Woche testen wir das halt nochmal manuell, haben aber schon einen Testcase geschrieben.
Und wenn wir dann sagen, ja okay, das ist jetzt abgetestet, aber es ist doch ein aufwendiger Test für den manuellen Teil, dann würde der in die Automatisierung wandern. Oder wenn da nochmal ein Fehler auftritt, dann sowieso, dann können wir uns nicht einfach darauf verlassen, dass wir immer mehr Cases in den manuellen Teil packen, die aber auch kritische Features als einzige Instanz abtesten, sondern dann wollen wir diesen doppelten Boden haben.
Und dann können wir den halt einziehen und die automatisieren. Ja, oder auch sowas, was halt manuell schwierig dann abzutesten ist, wie dieses Beispiel mit den, ich weiß nicht, wie viele Sendungen die ZF Mediathek hat, aber dass man manuell in jede Sendung reinklickt und man merkt, okay, bei ein paar Sendungen finde ich dann immer diesen gleichen Fehler.
Naja gut, dann sollte ich das vielleicht mal automatisiert abdecken, weil dann kann ich ja wirklich alle einfach mit dem gleichen Test einmal abfrühstücken. Da würde ich gerne gucken, mal kurz abbiegen, weil da stelle ich mir das auch mit den Testdaten, schwierig vor, wie ihr damit umgeht, weil also die Mediathek so ist ja ständig anders. Also mache ich was dazu, dann läuft das ab, dann kommt was Neues, dann gibt es neue Folgen und so.
Wie berücksichtigt ihr das oder habt ihr quasi da ein fixes Set, auf dem ihr arbeitet? Also automatisiert berücksichtigen wir das, indem wir, jetzt wird es sehr speziell, also wir nutzen Test Engine, da gibt es einen sogenannten Data Provider sozusagen.
Das heißt, wir klicken einmal durch die App durch und scannen sozusagen, okay, welche Sendung gibt es da oder wir sagen wirklich, okay, gehe einfach jede Sendung durch, bis es unten keine mehr gibt sozusagen, bis die doppelt auftritt, wenn man draufklickt zum Beispiel und führe jeweils immer den gleichen Test darauf aus.
Das ist so eine, da muss man es natürlich sehr generalisieren, was aber ich glaube in Ordnung ist, weil man eben eigentlich die Testabdeckung erhöht und wir eben das Manual Testing ja auch dazu noch haben. In Automation kann man natürlich keine Validierung machen, hingegen so ist der Titel, ist das Deutsch richtig oder so oder ist das eine Rechtschreibfehlung, können wir bestimmt auch, aber ist es vielleicht nicht mehr, ist nicht mehr, ist nicht mehr kostentechnisch nicht mehr zu.
Ja, also macht glaube ich nicht so viel Sinn und das natürlich im manuellen Bereich kann man natürlich solche Sachen dann eher sehen, ist irgendwas sinnvoll oder irgendwie richtig oder sieht es richtig aus zum Beispiel auch. Also gerade so, wenn sich irgendwas überlappt, die Automatisierung erkennt das immer oder auch wenn das irgendwie nur versteckt ist oder so, versucht dann auch drauf zu klicken, da wird es dann wahrscheinlich dann failen. Weil der Klick dann nicht funktioniert.
Aber ja, das sind so Sachen, die halt mit dem menschlichen Auge viel, viel schneller erkennbar sind und automatisiert theoretisch abdeckbar sind, aber ein Riesenaufwand dahinter wäre, ja.
Wenn wir jetzt auf die Fehlerfindung kommen, also ihr habt ja diese drei Bereiche, den explorativen Test, den manuellen strukturierten, so nenne ich es jetzt einfach mal, und den automatisierten und ihr guckt auf die Zeit, die ihr da jetzt schon gearbeitet habt, ein Jahr glaube ich jetzt, wo ihr da so gewirkt habt. Also die größten Klopper, wo habt ihr die gefunden? Es ist tatsächlich relativ verteilt, muss man sagen.
Also dann geht plötzlich was im Player kaputt, wo man dann irgendwie nicht mehr das Vollbild machen kann. Irgendwelche Inhalte werden nicht geladen, das findet dann die Automatisierung eben an den Stellen, wo das passiert. Das mit dem Player wäre eher der manuelle Teil.
Und dann gibt es wirklich so abgefahrene Sachen, die nur auf irgendwie totalen Randgeräten passieren, die dann eigentlich nur... nur auffallen, weil wir einen Fehler eingrenzen wollen, also da eher explorativ unterwegs sind, kann man wirklich nicht so sagen, dass jetzt etwas davon am besten performt, um Fehler zu finden. Also hast du für die Fehlerfindung alle Ebenen haben da ihre Berechtigung?
Ja, tatsächlich ist es wahrscheinlich die Kombination, die dann eben auch dazu führt, dass wir so viele Fehler finden. Ja, also ist eigentlich die Bestätigung dafür, dass wir es machen sollen. Jetzt hören ja hier einige zu. Das ist in dem Podcast so, also ich hoffe es zumindest. Meistens hört es immer zu. Und ich glaube, viele stecken auch in dieser Thematik drin. Testautomatisierung ist jetzt da, wird so als das Wundermittel gepriesen.
Da kann man jetzt alles machen und lösen und quasi ganz viel Ressourcen einsparen und sowas. Und in der Praxis, wie ihr jetzt auch gerade erzählt habt, ist es ja doch... Es steckt der Teufel im Detail und da macht die Kombination schon Sinn. Was würdet ihr denn den Hörern hören? Was würdet ihr den Hörerinnen mitgeben als Tipps, sich diesem ganzen Druck auch zu entgehen oder was dagegen zu stellen?
Ja, also am Ende funktioniert es wahrscheinlich am besten, wenn man schaut, okay, also oft ist das Setup, dass das Team das einfach mitmachen soll. Die Entwickler sollen einfach ihre automatisierten Tests schreiben und dann passt das schon irgendwie. Und das ist natürlich was, das muss man entsprechend priorisieren und da muss man auch entgegen aller Deadlines etc. Dann konsequent bleiben und darauf achten, dass diese Testsuits durchlaufen.
Und das, was wir da in der Realität einfach oft sehen, ist, da kommt was von der Seite rein, da ist die nächste Deadline, dann wird das Testing hinten angestellt, das muss jetzt fertig werden. Dann failen plötzlich ein Drittel der Tests. Im nächsten Sprint hat man keine Zeit, die wieder zu fixen. Und das ist so ein bisschen das Problem mit der Automatisierung, die ist wartungsintensiv.
Gerade wenn weiterentwickelt wird, wenn vielleicht sogar mehrere Teams zusammenarbeiten und dann für den Release kann. Und dann müssen die Daten, auch die Ergebnisse alle gemerged werden.
Da gehen Sachen zwangsläufig kaputt, weil sich die Software ändert, weil Fehler eingebaut werden etc. Und das sich einfach mal über einen Zeitraum anzugucken, ist meistens ein ganz gutes Argument, um da zumindest ein gewisses Kontingent, sei es eine Ressource, sei es vielleicht auch eine halbe Ressource oder 20% des Sprints oder welche Größenordnung man auch immer wählt, sich dafür zu blocken, dass man auch schaut, dass die QA flexibel und aber eben auch funktionierend ist.
Weil am Ende ist auch niemandem geholfen, wenn wir dann das Feature fertig haben zu der Deadline, aber es kaputt. Ja, super. Das ist ein schöner Tipp auch noch für die Community. Ich glaube, das kann sich jeder mitnehmen, weil das Thema haben einige. Ja, ich sage vielen lieben Dank. Hier Rede und Antwort gestanden, ein spannendes Projekt.
Finde ich toll, dass ihr da auch mal so ein bisschen einen anderen Weg geht und nicht nur sagt, wir müssen alles automatisiert machen, sondern einfach eine gute Kombi da auch mit Hirn und Verstand. Also eine Predigt sozusagen. Finde ich ganz, ganz wichtig und danke, dass ihr hier im Podcast warst und ich wünsche euch noch ganz viel Spaß bei der Konferenz. Vielen Dank. Vielen Dank dir auch und viel Erfolg mit den weiteren Fragen. Danke. Danke. That's the game we play