Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Ich bin dein Host Ritschi und habe wieder eine Folge vom QS-Tag 2023 aus Frankfurt mitgebracht. Im Gespräch waren Felix, Alicia und Christoph und wir haben uns über ein sehr spannendes Projekt bei der Hook Coburg unterhalten und zwar hatten wir eine spannende Reise, was die Testautomatisierung
ihrer mobilen App angeht. Mit ein paar mutigen Schritten, wie zum Beispiel das Wegwerfen einer ganzen Testautomatisierungslösung und der Aufbau einer komplett neuen, was man nicht alle Tage macht. Über ihre Erfahrungen erzählen sie jetzt hier im Podcast. Und wenn du Spaß an diesem Podcast hast, Inspirationen kriegst, neue Gedanken und was lernst oder auch schon mal was gelernt hast, dann bewerte doch gerne den Podcast auf den üblichen Plattformen und schicke mir Feedback
an [email protected]. Und jetzt viel Spaß bei der Folge. Hallo, schön, dass ihr da seid hier beim Podcast Software Testing live am QS-Tag. Ihr seid der erste Slot heute, ganz frisch die Technik aufgebaut und jetzt geht's los mit den Aufnahmen hier im QS-Tag. Jetzt sitzen wir hier zu viert, volle Truppe. So viele Gäste hatte ich noch nie im Podcast, muss ich auch ganz ehrlich gestehen, aber ich denke, wir kriegen das gut hin. Und ja,
ihr habt so das Thema Testautomatisierung, Mobile App. Also, wir dürfen es ja sagen, ihr seid von Hook, von der Versicherung. Die kennt der eine oder andere. Und ja, ihr habt quasi da einen Weg beschritten, wie ihr da eure App testet und so. Erzählt mal ein bisschen, was war denn so eure Herausforderung? Wie ging es denn los überhaupt? Alle schauen mich an. Ja, also es war ein recht steiler Weg, muss man sagen. Also,
wir testen ja die Hook mein Auto App, das ist die Telematiklösung der Hook Hobo. Und wir waren von Anfang an der Meinung, dass wir eben eine Testautomatisierung benötigen. Also, wir sind auch ein agiles Team. Dementsprechend hat das auch ganz gut gepasst. Ehrlicherweise sind wir aber halt ohne große Vorbereitung da mal rangegangen. Also, wir haben einfach losgelegt, wie es auch der agile Gedanke eben ist. Und ja, sind eben damit ein bisschen, auf Deutsch gesagt,
hingefallen, möchte ich mal so sagen. Das hat nicht funktioniert. Unsere erste Lösung bei der Testautomatisierung mussten dann eben mehr Kapazitäten in den manuellen Test stecken. Und irgendwann sind wir aber dann trotzdem zu dem Punkt gekommen, wo wir gesagt haben, naja, wäre trotzdem aber schön, wenn wir eine funktionierende Testautomatisierung hätten. Aber was hat denn konkret nicht funktioniert? Weil ich glaube, da können sich wahrscheinlich
die einen oder anderen Zuhörer*innen auch identifizieren. Ja, ich glaube, wenn man es runterbricht, hat unsere Testautomatisierung Aufwände produziert, statt irgendwie zu entlasten. Das ist schon mal ein ganz schwieriger Punkt. Und das Zweite war auch, wir hatten kein Vertrauen in die Testautomatisierung. Also, wir haben Runs gehabt, die waren komplett grün in der Testautomatisierung, währenddessen im Regressionstest 20, 25 kritische Fehler gefunden
wurden. Das heißt, das Ziel der Testautomatisierung wurde komplett verfehlt, weil sie wollten ja irgendwie die QA unterstützen, ein bisschen entlasten, auch für Sicherheit sorgen. Und das war einfach nicht der Fall. Also, das sind ja die zwei Hauptaspekte, wo man sich davon wünscht. Und das war leider nicht da. Okay. Ja, und also ihr habt das Problem erkannt. Das ist gut. Und ihr wolltet aber trotzdem eine Testautomatisierung haben, weil die manuellen Aufwände auch sehr
hoch waren, nehme ich an. Also, tatsächlich haben wir sie erst mal komplett eingestellt. Also, wir waren irgendwo an dem Punkt, wo man sich dann überlegt hat, okay, machen wir weiter oder stellen wir das Ganze ein. Wir haben uns dann dafür entschieden, das Ganze einzustellen, weil es einfach kostennutzendechnisch keinen Sinn mehr gemacht hat. Und auch in agilen Projekten ist der Kosten-Nutzen-Faktor einfach da. Wir können jetzt nicht sagen, okay, wir machen nur eine
Testautomatisierung, dass wir es auf der Fahne haben. Wir müssen sagen, wir machen eine Testautomatisierung. Das ist es ja am Ende nicht. Also, es muss ja auch was bringen. Dementsprechend haben wir es tatsächlich eingestellt. Ganz lange sogar, ganz lange in Anführungsstrichen. Wir haben vier, fünf Monate überhaupt nichts gemacht in Richtung Testautomatisierung, haben dann das Scheitern im Endeffekt aufgearbeitet und haben dann einen komplett neuen Anlauf gemacht. Also,
wir haben auch nichts verwendet von dem, was wir davor genutzt haben. Einen kompletten harten Cut gemacht und komplett neu angefangen nochmal. Die Besonderheit war, glaube ich, auch, wenn man überlegt, wir haben 2018 angefangen, die App zu entwickeln. Am 2018, nach wenigen Monaten, gleich mit der Testautomatisierung angefangen und haben dann, Christoph, ich muss mich ein bisschen orientieren, wir haben angefangen 2022, Ende des Jahres. Wir haben Mitte 2022 die
Testautomatisierung abgebrochen. Das heißt, da steckten vier Jahre Arbeit drin, dann dieses halbe Jahr Pause und jetzt sind wir seit Ende 2022 eben mit der neuen Lösung am Start. Ja, das finde ich einen total mutigen Schritt, weil, also ich kenne das in Unternehmen häufig anders. Das lässt man weiterlaufen, weil man hat es ja, auch wenn es keine Aussage mehr hat,
man hat schon so viel reingesteckt und jetzt bloß nichts ändert. Also, ich bin ja auch da ganz mutig zu sagen, nee, machen wir nicht mehr, drehen wir ab und fangen von Neuem an. Ja, war auch kein leichter Schritt. Also, wir haben das halt aus dem CoA-Team raus initialisiert, dass wir dann auch wirklich mal aufgezeigt haben, hey, das bringt uns einfach nichts. Also, wir sind besser dran, wenn wir nur rein auf die manuelle CoA setzen, da wir auch sehr gute manuelle
Tester haben. Natürlich kam aber dann auch vom Management halt die Seite, aber wir haben ja so und so viel Geld schon reingesteckt. Was ist damit? Und das waren harte Diskussionen. Also, am Ende tat es auch furchtbar weh zu sagen, ja, das ganze Geld war für die Cuts im Endeffekt, weil es uns Stand jetzt einfach nichts gebracht hat. Also, das hat ja auch, glaube ich, was mit dem Reifegrad des Teams zu tun. Ich persönlich glaube, dass wir tatsächlich zu
früh angefangen haben. Ein Team muss sich erstmal finden, muss auch seine Rolle finden und muss auch erstmal mit seinen Aufgaben klarkommen. Und wenn du dann eben eine Testautomatisierung obendrauf packst, die nur Aufwände erstmal erzeugt, dann ist jeder natürlich auch davon genervt und sagt, bloß weg mit dem Zeug. Ja. Könntest du uns noch ein bisschen reinholen, technologisch. Eine App klingt ja, das kann ja
ganz viel sein. Das kann eine kleine Website sein, die nennt man dann App oder eine richtige App, eine Native App. Aber was habt ihr denn da für einen Technologiestack, den ihr da überhaupt bedienen müsst? Ja, also im Endeffekt ist es eine Technologie, dass die App, mein Auto, eben in Verbindung mit einem Telematik-Sensor arbeitet. Und dieser
Telematik-Sensor zeichnet die Fahrdaten des Nutzers auf. Und anhand von den Fahrdaten kann der Nutzer eben Beitrag sparen, indem er eben sehr sicher fährt und zum Beispiel Kriterien wie Geschwindigkeit, Beschleunigung, Brems- und Lenkverhalten dann ausgewertet werden. Und das ist natürlich ein enormer Technologieaufwand und im Endeffekt ja auch eine monetäre Leistung. Also wenn das nicht funktioniert, melden sich die Nutzer bei uns
wirklich sofort. Und sind das native Apps, die also wirklich auf Geräten laufen oder also so eine iOS-App, Android-App, so wie man sich's vorstellt? Genau, also die sind im App-Store, im Play-Store erhältlich und werden dann heruntergeladen. Ja, ja, okay. Also es kam dann die Entscheidung, wir machen's neu und dann?
Und dann hoffentlich richtig. Genau. Ja, das ist ja die Gefahr, wenn du sowas einstellst und sagst, du willst das komplett neu machen, dann hast du schon einen gewissen Druck, es auch diesmal richtig zu machen, weil wenn dieser Versuch ein zweites Mal scheitert, dann ist das natürlich noch schlimmer. Ja, wir haben das gemacht. Wir haben das eher
klassisch gemacht. Also wir haben ganz viele interne Workshops gemacht, wo wir einfach mal die Leute gefragt haben, hey, warum hat's denn aus deiner Meinung nach nicht funktioniert? Also wir haben das wirklich sehr detailliert aufgearbeitet, haben dann auch aus den verschiedenen Rollen mal gefragt, vielleicht was möchte ein Product Manager, was möchte ein Testmanager,
was möchten die manuellen Tester, was möchten die Entwicklungen? Dann alle mal ein bisschen auf einen Punkt zu bringen, dass man sagt, okay, wir brechen das jetzt mal runter und definieren für uns zwei Ziele. Das heißt, was haben wir gemacht? Wir haben das Scheitern aufgearbeitet, haben uns dann entschieden, okay, wir machen weiter, das war ganz wichtig und haben dann aber gesagt, okay, wir definieren dafür einen Anforderungskatalog. Macht man
in der agilen Welt, glaube ich, normalerweise nicht. Da ist es eher so dieses schnelle Scheitern, man probiert was aus, wenn es nicht funktioniert, macht man eben was anderes. Bei so einem Umfang, also eine Testautomatisierung ist ja sehr, sehr umfangreich, kostet auch eine Menge Geld, muss man ehrlicherweise sagen. Da muss man sich einfach Gedanken davon machen. Das haben
wir im ersten Schritt nicht gemacht. Ich glaube, daran sind wir auch gescheitert. Und im zweiten haben wir eben wirklich einen Anforderungskatalog runterdefiniert, wo wir gesagt haben, okay, wir definieren wirklich runter, was soll dieses Tool können, was soll es auch vielleicht nicht können. Also auch die Grenzen irgendwo abgesteckt. Und am Ende des Tages sind wir
dann, glaube ich, zu zwei großen Zielen gekommen. Und die zwei großen Ziele waren, dass ein nicht technischer Anwender, also ein Nichtentwickler, im Endeffekt Testfälle spezifizieren kann und auch ausführen kann. Das geht in Richtung manueller QA, soll mit im Boot sein, soll Testfälle spezifizieren können, soll sie ausführen können, also unterstützt das die QA. Und der zweite große Faktor, das geht ein bisschen in Richtung Mobile Testing,
also eben die Gerätevielfalt. Alice hat es wunderbar erklärt, die App hat auch irgendwo einen monetären Anreiz. Wenn die Fahrtaufzeichnung nicht funktioniert oder Features nicht funktionieren, hängt da ein Versicherungsprodukt dran. Und die Deutschen sind da sehr, sehr sensibel bei den Versicherungsprodukten, weil jeder hält sich für den besten Autofahrer und geht
auch davon aus, dass er die 30 Prozent auf jeden Fall abräumt. Wenn du dann halt irgendwie einen Bug drin hast und dann geht mal drei Wochen die Fahrtaufzeichnung nicht, das ist ein Fiasko. Da steigt uns der Kunde aufs Dach, der Support steigt uns aufs Dach und am Ende dann auch die Abteilungsleiter, weil das türmt sich alles weiter auf. Und da ist halt die Schwierigkeit für uns, wir bieten das ja auf Android und iOS an. iOS kriegt man noch
ganz gut abgedeckt. Die haben jedes Jahr ihr neues Modell, die haben drei Displaygrößen, die haben meistens immer das neueste OS gleich installiert, kriegst du halbwegs ganz gut hin. Aber auf Android, also wenn ich schätzen müsste, glaube ich, gibt es eine dreistellige Anzahl an Kombinationen mit Geräten, wahrscheinlich noch mehr mit Typen und mit OS-Systemen, das kriegst du nicht abgetestet. Da kannst du die besten Tester haben, das fehlt dann einfach
an der Quantität. Du kriegst es nicht hin. Und deswegen war das zweite Ziel eben die Gerätevielfalt zu verbessern. Deswegen gesagt haben, okay, wir wollen einen Stack haben von 60, 70 Prozent Testautomatisierung, höher wollen wir gar nicht. Aber dafür läuft es auf zehn verschiedenen Geräten und hilft uns dadurch auch mehr die Qualität zu sichern. Das heißt, runtergebrochen waren es zwei große Ziele. Einmal eine Anwenderfreundlichkeit und einmal eine Qualitätssteigerung durch Gerätevielfalt.
Spannend, also wirklich auch zwei Sachen, an denen man sich auch orientieren kann. Weil häufig, also so Ziele, da gibt es ja dann ganz viele Wünsche. Du hast gesagt, Projektleiter, Produktowner, Testmanager, alle haben so ihre Vorstellungen, was da passieren soll. Das ist ja meistens ein Blumenstrauß. Aber sich da noch zwei zu committen, das finde ich schon gut. Und das da runterzubrechen, die Aufarbeitung, das ist eine tolle Sache. Das heißt, ihr
habt die zwei Ziele gehabt. Das war ja Ende letzten Jahres schon so weit oder ist das schon in diesem Jahr jetzt dann der zeitliche Faktor? Ja, konkret glaube ich im Sommer haben wir die Testautomatisierung beendet, sprich auf Eis gelegt. Dann hatten wir glaube ich im August diese Workshops. Das war auch echt toll. Also wir haben da auch einen anderen Services, der auch eine mobile App entwickelt, die noch überhaupt keine Testautomatisierung hat, mit reingenommen und haben dann praktisch
in einem Workshop von verschiedenen Teams Pseudo-Lösungen ausarbeiten lassen. Also wirklich auf der grünen Wiese, wie würde die perfekte Testautomatisierung für euch aussehen. Solche Workshops waren das. Also wirklich auch mal was Neues probiert. Und wir haben dann August, September eben diesen Anforderungskatalog gemacht. Da haben wir uns auch recht viel Zeit genommen. Also wir haben auch wieder von verschiedenen Rollen Input
geben lassen. Das hat auch ewig gedauert, bis das Ding mal stand, weil es waren ja auch irgendwie konkurrierende Ziele. Und da musstest du diese auflösen und dann wieder definieren. Also das war für ein agiles Team eigentlich nicht üblich, sage ich mal, aber notwendig.
Und dann haben wir im September, Oktober dann extern ausgeschrieben, aber mit der Prämisse, dass der Anforderungskatalog eingehalten wird und dass es einen POC gibt, also einen Proof of Concept, dass praktisch mindestens drei Testfälle eingereicht werden müssen und wir die uns erstmal angucken. Ich glaube, wo wir halt auch hingefallen sind, war, dass wir nicht geprüft haben, ob es wirklich auf uns passt. Das war andersrum. Wir haben uns
auf das Tool angepasst oder auf die Automatisierungstechnologie. Und dieses Mal wollten wir es andersrum machen. Und deswegen haben wir gesagt, nee, wir wollen erst die Testfälle sehen, gucken, ob das zu uns passt und erst dann geben wir das ok. Weil auf dem Papier kann immer alles schön aussehen, aber am Ende muss es auch für uns stimmen. Und so kam Firma Imwurst und Christoph dann ins Spiel. Ja, genau. Also hast du ja schon gesagt, ihr wart ja vom Preisvergleich eigentlich schon
relativ weit. Oft ist es bei uns so, wenn wir dazu kommen, müssen wir viele von den Steps, die ihr jetzt schon davor gemacht habt, eigentlich, ja, ist das bei uns Standard, dass wir sowas wie einen Anforderungskatalog erstmal mit dem Kunden zusammen definieren, dass da wirklich dann die richtigen Anforderungen oder die Tools nach den richtigen Anforderungen ausgesucht werden. Da habt ihr ja schon ein bisschen Vorarbeit geleistet. Das war ja schon
mustergültig eigentlich. Und ja, auch so von den Testfällen und so waren die auch schon sehr hohen Reifegrad gehabt. Also das war für uns schon mal eine gute Voraussetzung, irgendwo überhaupt zu starten. Genau, hatten dann trotzdem nochmal die ganzen Anforderungen verfeinert am Anfang, im Kriterienkatalog runtergeschrieben, gewichtet und genau, haben dann ein paar Tools ausgewählt und die eben nach den Anforderungen einsortiert.
Also es ist ja total spannend, weil es ist ja eigentlich, ist ja der Bilderbuchprozess, wie man ein Tool auswählt oder wie man da hinkommt. Da steht ja in allen Lehrplänen fast drin, hinten das Kapitel Tools oder sowas. Wie macht man Pilotprojekte, wie macht man Forum, man macht einen Proof of Concept und all diese Sachen. Und in der Praxis ist das oft so ein Kuddelmuddel aus irgendwas, was da passiert. Also das ist ja echt schön
gemacht, wie im Lehrbuch. Ich glaube, das lag wirklich dran, dass wir beim ersten Mal das eben nicht so gemacht haben. Genau, wir haben uns dann einmal die Finger verbrannt und dann… Also die Situation haben wir öfters bei Imbus, dass man wirklich halt irgendwo hinkommt, wo es dann heißt, die Testautomatisierung
ist gescheitert und so weiter. Und ja, meistens dürfen wir dann oder sammeln wir die Anforderungen an, weil irgendwo muss man ja überhaupt die Tools bewerten können, was im Vorfeld meistens nicht gemacht wird. Da wird halt das Nächste Beste irgendwie gefühlt genommen, was ja Google ausspuckt oder so. Und genau, da muss man also wirklich gezielt darauf achten, passt
das auch wirklich zum Team? Wer soll dann mitarbeiten können? Sollen die manuellen Tests eben auch irgendwo in der Lage sein, Testfälle zu spezifizieren oder ist das rein irgendwo von Techies zu realisieren? Genau, dass man da gezielt drauf schaut. Und welcher Toolstack ist es dann geworden? Also in dem Fall ist es jetzt genau Robot
Framework, weil wir mittlerweile echt sehr gute Erfahrungen damit gemacht haben. Ist auch im Mobile-Bereich, also auch gerade für, dass man beide Welten dann vereinen kann, dass wir denselben Testfach wie Android und iOS verwenden können, dass dann wirklich nur auf unterster Ebene unterschieden wird, dass wirklich die Business Keywords, heißt bei uns und so weiter, alles gleich bleibt und verwendet werden kann. Genau, und auch
oben in einer natürlichen Sprache das Ganze formuliert werden kann. Also man muss keine Methoden schreiben können oder sonst irgendwas, sondern kann seine Keyworder verwenden und daraus dann seine Testfälle zusammenbauen und das Ganze auch noch Testdaten getrieben machen, wenn man will und so weiter. Und genau, da haben wir bisher sehr gute Erfahrungen gemacht und hat auch hier in dem Umfeld eigentlich perfekt gepasst.
Wie habt ihr denn das dann konkret begonnen aufzubauen? Wie ging denn das dann voran? Das war dann durch Kurzfristig letztes Jahr. Das war dann noch kurz vor Weihnachten. Ich meine, ihr habt ja so ein bisschen Erwartungen schon gehabt. Ihr habt ja schlechte Erfahrungen davor gehabt und wolltet dann irgendwo auch schnell Ergebnisse sehen können und auch
wissen, dass das halt wirklich funktioniert, was man vorschlägt. Genau, und dann haben wir ein bisschen nochmal gegen Ende des Jahres lang geklotzt und haben es, glaube ich, dann ganz gut noch hinbekommen. Ich glaube, dass wir den ersten Proof-Konzept dann mal vorstellen konnten. Also ganz konkret haben wir das so gemacht.
Wir haben Risk-Based Testing bei uns aufgesetzt im Endeffekt. Also wir haben uns die Testfälle des Regressionstests angeguckt, haben die dann eben bewertet nach dem Risiko, was dahintersteckt und haben dann im Endeffekt nochmal unsere Priorisierung nach P1, P2, P3 und P4 neu strukturiert. Das war ein bisschen so die Vorarbeit zu der Geschichte. Und ich glaube, 30 Testfälle
waren es dann. Das haben wir dann bis Jahresende eben nochmal automatisieren lassen. Man kann es ja ganz ehrlich sagen, man hat natürlich auch Anforderungen oder Erwartungen an den Dienstleister und wir wollten natürlich auch Christoph und dem muss ein bisschen challengen. 30 Testfälle sind ein Wort. Aber sie haben es geschafft und das auch nicht schlecht. Also die waren echt super, die Testfälle. Das war auch der erste Eindruck. Deswegen
ging es auch weiter. Aber das war ein bisschen für uns so die Challenge, zu sagen, Robot Framework klingt alles wieder super. Die drei Testfälle waren auch gut, aber wie schaut es denn mit der Masse aus? Also kriegen wir da auch die PS auf die Straße? Dementsprechend waren das tatsächlich 30 Testfälle dann nochmal, ich glaube innerhalb von zwei Monaten. Und du hattest vorhin, glaube ich, noch gefragt, die Frage habe ich, glaube ich, übergangen,
was die Technologie davor war. Wir hatten Cucumber mit der Gherkin-Syntax. Also eigentlich das klassische, muss man sagen. Das haben, glaube ich, die letzten Jahre ganz viele gemacht. Es ist halt ein völlig anderer Ansatz. Also der Cucumber mit Gherkin-Ansatz ist ja meines Erachtens behavior-driven. Den Ansatz, den wir jetzt machen, ist keyword-driven. Und wir wussten es selber nicht, aber scheinbar ist für unser Team ein keyword-driven-Ansatz
eben besser oder halt praktikabler. Aber das musst du auch erstmal rausfinden. Da gibt es so viele Bücher dazu und so viele Lehrpläne wahrscheinlich. Aber am Ende des Tages musst du wirklich gucken, was passt zu meinem Team. Also du musst es ausprobieren. Da sagst du, was total richtig ist. Wir hatten auch im Podcast schon zwei, drei Folgen zu behavior-driven Development. Und ich kenne es auch bei Unternehmen. Und die finden es
immer total klasse. Und dann machen die auf einmal alles. Dann werden alle Anforderungen, Akzeptanzkriterien dann wild in diese Sonntags gepackt, dass dann irgendwelche Monster entstehen werden und überhaupt nicht mehr drauf geschaut, was braucht das Team eigentlich? Wer kann denn sowas überhaupt schreiben? Kriege ich, kann ich meine Aufgaben überhaupt in sowas formulieren? Das ist ja nicht immer gegeben. Also es gibt einfach auch dann andere, helfen dann anderen.
Also das ist schon ganz wichtig, glaube ich, dass man sich da selber schaut, was braucht das Team? Wie kann man da Testfälle gut schreiben? Ja, ich denke, das ist auch ein ganz wichtiger Punkt, dass auch die manuellen Tester, wie ich jetzt auch eine bin, damit dann auch umgehen können. Bei unserem ersten Ansatz haben wir uns da eher schwer getan. Und ich denke, jetzt haben wir eigentlich die perfekte Lösung, dass die manuellen Tester ihr Fachwissen einbringen. Und Imbus in
dem Fall eben das technische Know-how. Und das Zusammenspiel funktioniert da ganz gut. Und das ist ja auch wichtig, dass es dann am Ende funktioniert, dass wir dann auch wissen, was da geschrieben wird, das verstehen können und eben anhand von den Keywords dann auch selbst anwenden können. Also, dass wir auch in der Lage sind, damit selbst zu arbeiten und im Endeffekt dann den technischen Ball wieder zurückspielen, wenn da eben Keyword fehlt, dass das dann auch
wieder umgesetzt wird. Wie war denn das für euch, also dieser Übertrag, also in dieses Keyword Driven reinzugehen und die Keywords mal überhaupt zu finden und jetzt Testfälle damit zu schreiben? Wie war denn für euch da diese Transformation dahin? Ja, im Endeffekt, wir hatten ja auch dann einen Workshop, wo wir das zusammen dann nochmal ausgearbeitet haben. Es waren ja schon bestimmte Keywords definiert. Anhand von denen haben wir dann unsere ersten Testfälle auch selbst geschrieben.
Und dann kriegt man da so langsam ein Gespür dafür, okay, was haben wir schon, was brauchen wir noch? Und da hat es dann eigentlich ganz gut funktioniert. Weil ja eure manuellen Testfälle eigentlich auch schon Keyword Driven waren, also zumindest sehr in die Richtung. Also, ich glaube, so groß war die Umstellung dann wahrscheinlich gar nicht. Und was ich auch denke, was wirklich wichtig war, war halt, dass wir von Anfang an eigentlich immer einen Austausch hatten.
Also, es war jetzt nicht irgendwie, dass wir die 30 Testfälle stundenheimlich irgendwie entwickelt haben und dann mal hingeknallt, sondern das hat wirklich von Anfang an mehr regelmäßig der Austausch stattgefunden hat und Zwischenstände präsentiert werden, dass man sagt, passt das so für euch? Ist es zu abstrakt? Muss man nochmal Anpassungen machen? Und so weiter. Also, das ist für mich auch immer ganz wichtig, dass man wirklich von Anfang an das komplette Team mitnimmt,
nicht irgendwie nur vor sich hin programmiert. Dann haben wir gesagt, so sieht es jetzt aus. Und viel Spaß. Da war auch etwas, was bei unserer Analyse stark rausgekommen ist, dass ein Problem war, da ist, wenn du das Testautomatisierungsteam komplett isolierst, also wenn das wie ein eigenständiges Team ist und man wirklich, wie es Christoph beschrieben hat, die Testfälle nur rüberwirft und sagt, automatisieren wir bitte und dann lassen wir die irgendwann laufen. Und
das ist ein grundsätzlich falscher Gedanke aus meiner Sicht. Also, du musst es wirklich hinkriegen, dass du das komplette Team da mitnimmst. Da muss im Endeffekt der Testmanager muss da mit drin sein, der muss sich technisch auskennen, die manuellen Tester müssen sich auskennen. Also, du musst im Team auch die Rollen ein bisschen tauschen manchmal. Das ist klar ungewohnt,
wenn du dann in so einer IDI plötzlich irgendwelche Keywords eingeben musst. Das fühlt sich erst mal falsch an, weil es sich anfühlt wie eine Entwicklungsumgebung, ist es ja auch, und man halt einfach kein Entwickler ist. Aber diese Hürde, glaube ich, zu übergehen und dann wirklich das ganze Team einzuholen, das ist für mich eigentlich der Game Changer. Weil wenn du das isolierst, dann fühlen sich die Testautomatisierer isoliert,
sie unterstützen sich nicht gegenseitig. Und was wir auch erkannt haben, ist, dass jeder seine Stärken und Schwächen hat. Also, ein Testautomatisierer ist halt technisch stark, ist aber vielleicht fachlich nicht so tief drin, dass er die Testfälle versteht. Ein manueller Tester ist fachlich immens stark, der versteht genau, was der Testfall meint, weil er ihn schon hundertmal gemacht hat. Er weiß auch, wie die Anwendung reagiert, hat aber das Technische nicht.
Und das ineinander zu kriegen, daran, glaube ich, steht und fällt es am Ende dann auch. Ja, auf jeden Fall. Sehr spannend. Wenn man jetzt heute so drauf schaut, wie viele Testfälle sind denn jetzt entstanden? Also, es waren erst drei, dann waren es 30 und so. Jetzt baut ihr selber Testfälle schon. Was ist denn da jetzt so passiert? Wir haben ja jetzt Oktober, das ist ein dreiviertel Jahr. Also, aktueller Stand haben wir ein Drittel von unserem Regressionstest automatisiert,
teilweise sogar vollautomatisiert. Also, das ist ja auch immer ein bisschen so die Trennung, automatisiere ich einen Testfall oder vollautomatisiere ich ihn? Vollautomatisieren bedeutet, du kannst ihn manuell komplett weglassen, manchmal kannst du ihn aber auch nur teilautomatisieren. Also, aktuell haben wir ein Drittel vom Regressionstest geschafft. Regressionstests sind so 150 Testfälle. Dementsprechend sind wir da eigentlich voll
im Lot. Ich habe am Anfang gesagt, 60 bis 70 Prozent ist die Zielvorgabe. Ich bin guter Dinge, dass wir da bis Jahresende hinkommen. Was aber auch nicht zu unterschätzen ist, ist halt die Infrastruktur außenrum. Also, wir haben auch Schnittstellentests aufgebaut, wir haben eine Anbindung an eine mobile Device Cloud aufgebaut. Das heißt, die Gerätevielfalt haben wir schon mal einen Hacken dran, auf jeden Fall. Das sind alles so Sachen,
wo drumherum noch mal auch dazu kommen. Auch die Wartung der Testfälle, was wir auch schon festgestellt haben. Die 30 Testfälle, die wir Ende 2022 geschrieben haben, die konnten wir im März, April schon wieder warten. Also, du musst auch eine permanente Wartung einbauen, aber wir sind zufrieden. Also, wir sind stabil unterwegs, möchte ich behaupten. Wir rennen jetzt nicht los und sagen, wir machen jetzt nur Quantität. Ich könnte jetzt auch sagen, wir haben jetzt schon
80 Testfälle automatisiert. Das wird vielleicht vom Management ganz gut sich anhören, aber wenn diese 80 halt sehr flaky sind, also sehr instabil, bringt das mir wieder nichts. Ich meine, du hast ja gesagt am Anfang, das Problem war ja, ich habe die Automatisierung gehabt und dann gab es aber trotzdem kritische Probleme draußen. Trotzdem musste man alles manuell testen. Und jetzt habt ihr einen Teil von einem Regressionstest von der Mario manuell
schon in dieser neuen Automatisierung durch. Und da ist jetzt natürlich schon die Frage, also als Manager würde ich jetzt auch fragen, ja, läuft denn das jetzt? Kann ich dem vertrauen? Oder wie ist so das Feedback auch? Oder wie seht ihr das quasi, die Stabilität nach außen? Bleibt die stabil quasi von den manuellen Tests jetzt über die Automatisierung auch? Also Stand jetzt haben wir noch nicht die Automatisierung wieder vollumfänglich mit
eingebunden in den Regressionstest. Einfach aus dem Grund, wenn wir das jetzt machen, dann würde ich ja diese 50, 60 Testfälle müsste ich ja komplett rausnehmen aus dem manuellen Test. An diesen Schritt sind wir einfach noch nicht gegangen. Das liegt nicht an der Qualität, also die Tests laufen. Es lag jetzt einfach ehrlicherweise an den Releases, die wir hatten. Also du kannst dir auch, das ist eine Erkenntnis, nicht bei jedem Release einfach mitlaufen lassen.
Du musst dir auch die Schwerpunkte setzen. Wir hatten jetzt im Sommer zum Beispiel einen Release, da ging es um die Fahrtaufzeichnung primär. Das kriegst du mit der Automatisierung nicht hin. Klar kannst du so einen Tech wahrscheinlich an eine Drohne rankleben und die fliegt dreimal um die Hocke, aber ob das produktionsnah ist und du hast auch andere Features, zum Beispiel das Pairing, also dieser Tech muss gepairt werden. Das kriegst du da noch nicht mit hin und je nachdem,
welche Schwerpunkte dein Release hat, geht es auch noch nicht. Was wir aber sagen können ist, dass die automatisierten Tests schon Fehler gefunden haben. Also wir lassen die regelmäßig laufen und wir haben dadurch, glaube ich, schon zwei, drei kritische Fehler gefunden, die wir halt im Sprintzyklus nicht finden. Die hätten wir erst im Regressionstest gefunden und da hat sie uns schon geholfen, also Fehler einfach früher zu finden, was ja auch wieder ein monetäres
Thema ist. Das heißt, ihr habt das quasi noch nicht voll in eurer Pipeline integriert, quasi ihr stoßt die auch manuell an, wenn ihr sie braucht, wenn ihr sie durchführen wollt, dann lasst ihr die Automatisierung laufen. Genau, also sie sind in Jenkins integriert, aber laufen halt jetzt dann, ich glaube, zurzeit jede Nacht mal. Aber es ist jetzt noch nicht, dass sie jetzt irgendwie, wenn die Software neu gebaut wird, dann sofort durchlaufen. Da schauen
wir dann, dass wir bis Jahresende noch hinkommen. Aber da müssen es halt auch sinnvolle Zeiten sein, also nicht, dass es vielleicht bei jeder Änderung mit durchläuft, weil dann sind wir wieder bei der Wartung von Testfällen, dass man da quasi nur am Warten ist und man da sagt, dass man eher vielleicht so ein Mikrobild oder so mal abtestet. Wir gehen jetzt ganz einfach recht langsam an,
muss man sagen. Also wir versuchen erst mal die ganze Infrastruktur drumherum aufzubauen, bevor wir Testfälle wirklich einsetzen, weil ich glaube, dann passiert genau wieder das, was davor passiert ist, dass die Testfälle vielleicht nicht so stabil sind, wie wir sie haben möchten, und dann dreht sich ganz schnell wieder die Stimmung. Und deswegen ist es halt bei mir ehrlicherweise, ich möchte die erst einsetzen, wenn ich wirklich sage, drumherum passt auch alles.
Es ist eine Anbindung zu unserem Jenkins da, zu unserem Chira, und dann setzen wir die ein. Aktuell kriegen wir das ganz gut hin, weil wir, wie gesagt, sehr, sehr gute manuelle Tester haben. Ja super, vielleicht schauen wir noch einmal auf die zwei Ziele, die ihr euch vorgenommen habt. Das eine war ja quasi, der manuelle Tester kann Testfälle selber schreiben. Das habe ich jetzt gehört, das ist für euch jetzt kein Problem. Genau, das funktioniert gut. Man muss natürlich
auch dazu sagen, dass es auch irgendwo Spaß macht. Also es ist ein bisschen Abwechslung, auch mal so tiefer in dieses Technische reinzugehen, und dadurch versteht man vielleicht den einen oder anderen Begriff von unseren Entwicklern auch besser, wenn man das einmal selbst ausgeführt hat. Deswegen ist es auch für uns natürlich ein spannendes Thema und ist dann auch ein schöner Erfolg, wenn man dann sieht, man schreibt das, es funktioniert, und am Ende drücke
ich den Knopf und es wird hoffentlich auch grün der Testfall. Ja, also da können wir Haken dran machen. Bei der Gerätevielfalt, wie habt ihr das gelöst? Du hast es kurz erwähnt, eine Cloud, wie macht ihr das konkret? Also das konkret ist eben angebunden mit einer Mobile-Device-Cloud. Das heißt, man kann dann bei der Ausführung sagen, ich möchte jetzt den Testfall auf iOS
oder Android laufen lassen und mit welcher Gerätekonfiguration. Also wir haben dann auch jetzt ein paar Konfigurationen hinterlegt, dass man sagt, das ist dann ein Gerät aus dem Pool,
zum Beispiel Samsung oder Google Pixel mit Android 13 oder 12. Also wir haben da schon ein bisschen Variationen mit reingenommen und haben jetzt drei Pakete mal definiert, wo wir sagen, das sind einmal Paket 1 und mit Prio 1, das sind die meistgenutzten Geräte, gerade bei Android, bei, wie der Felix schon sagt, bei iOS ist das Ganze ein bisschen weniger
kompliziert. Und genau dann so ein bisschen drunter priorisiert, dass man sagt, okay, im Dritten sind ja auch schon noch häufig genutzte, aber jetzt nicht mehr so die Top-Geräte, die wirklich weiter verbreitet sind. Und je nachdem kann man dann auch steuern, wie oft man die Automatisierung da drauf laufen lassen will. Und laufen die dann auf physischen Geräten irgendwo anders oder auf irgendwelchen virtuellen Tralafitik?
Genau, das sind wirklich physische Geräte, das war auch für uns wichtig, weil im Simulator, da findet man nicht alles. Also im Simulator macht vieles einfacher, aber genau die richtigen Ergebnisse bekommt man auf den richtigen Geräten. Und da hat man dann oft nochmal irgendwelche Seiteneffekte, die so nicht auftreten. Und genau, da ist das eigentlich schon wichtig. Und für uns ist dann auch wichtig, dass auch die manuellen Tester oder auch Felix als Testmanager
das Ganze auch versteht, was da drin passiert. Also, dass einmal mit dem Keyword-Tuning-Ansatz mal viel getan, aber auch, dass das Reporting dann verständlich ist. Also, wenn dann ein Fehler auftritt, dass man auch wirklich weiß, okay, warum ist das Ganze jetzt wehgeschlagen?
Was wäre erwartungswert gewesen? Was ist wirklich angezeigt worden? Jetzt bei der Mobile Device Cloud ist noch das Schöne dran, man hat eine Videoaufzeichnung dabei, kann sich einen Testfall dazu raussuchen, das Video dann nochmal anschauen, dass man wirklich danach verstehen kann, an welcher Stelle es schiefgelaufen ist. Das hat man halt bei so einer eher technischen Umsetzung, wie es davor war, dann nicht. Dann bekommt man halt einen Stack Trace und das hängt dann
erstmal wieder bei den Entwicklern. Wie ist denn das mit dieser Gerätevielfalt? Bringt euch die gerade was? Tauchen Fehler wirklich spezifisch auf einzelnen Geräten, Betriebssystemkombinationen auf? Wo ihr sagt, da müsst ihr dann nochmal ran? Also, wir haben ja auch die Schwierigkeit mit diesem Versicherungsprodukt. Das heißt, du musst ja auch angeben, auf welchen Geräten läuft die Software. Und da unterstützen wir
aktuell noch ab Android 7 und ab iOS 14. Und dann gibt es aber auch wieder die Sicherheitsvariante, oder das, ja, bei Versicherungen und Banken, unsere Testgeräte zum Beispiel, müssen irgendwann automatisch upgedatet werden. Logisch, weil die die neuesten Sicherheitsupdates brauchen. Das heißt, wir haben zum Beispiel gar keine physischen Testgeräte mehr mit Android 7. Ich glaube, das letzte hat jetzt Android 8 oder 9. Und so können wir halt trotzdem mal sagen,
ja, wir lassen jetzt mal ein Run auf älteren Geräten laufen von 7 bis 10. Was halt wichtig ist, wir monitoren das alles im Hintergrund. Also, wir haben Daten, wo wir sehen, auf welchen Geräten sind die User unterwegs. Das schauen sich Alicia und Janana monatlich an, oder portalsmäßig, je nachdem, was sich da tut. Das heißt, wir wissen eigentlich immer ganz genau, auf welchen Geräten sie unterwegs sind und können dann im Endeffekt auch diese Geräte anpassen.
Wir haben ja diese, wie Christoph gesagt hat, drei Pakete. Im ersten Paket, da muss es gehen. Also, auf den Geräten sind die meisten User unterwegs, da müssen die Tests passen. Auf den zweiten sollten sie gehen, die dritten können wir mal sporadisch mitlaufen. Aber das ist halt immer anpassbar. Und da musst du halt auch danach gucken. Du brauchst irgendwie Analytics im Hintergrund, wo du dir die Geräte auch mal raushuckst. Du kannst ja nicht würfeln.
Ja, klar. Woher muss denn die Info noch kommen? Ja, super. Also, ich finde, das ist ein ganz tollen Prozess, den ihr durchgemacht habt, weil also allein schon diesen Mut zu haben, da reinzugehen, das alles Alte wegzuschmeißen, neu zu machen und dann zu überlegen, was brauchst denn eigentlich mit den Zielen und das dann auch jetzt so sukzessive umsetzen. Und das klingt ja
auch, ihr seid sehr zufrieden damit. Das finde ich, das ist einfach mal ein gutes Ding. Und auch, also auch wie ihr das jetzt evaluiert, klingt für mich auch, dass es ja nicht jetzt wieder nur grüne Testfälle gibt und man weiß wieder nicht, was ist, sondern dass da auch wirklich jetzt auch Hand und Fuß dahintersteht. Und das finde ich ganz toll. Ja, ich bedanke mich sehr, dass ihr hier im Podcast Rede und Antwort gestanden habt. Alicia, Felix, Christoph, viel Spaß noch beim QS-Tag und
viel Spaß noch weiterhin mit eurer Testautomatisierung, würde ich sagen. Vielen Dank. Danke für die Einladung. Vielen Dank. [Musik]