Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute zu Gast Nikolaus Rieder von der Firma Schrag Seconet. Ich habe ihn bei einer Testbusters Night kennengelernt, die mein geschätzter Kollege Rudi Grötz organisiert und war ganz begeistert von Nikolaus Geschichte. Er hat sich daran gemacht, ein altes Test-Automatisierungs-Framework abzulösen durch eine neue Implementierung. Und von seinem ganzen Schmerz,
seinen Learnings und den Ergebnissen berichtet er uns heute. Viel Spaß bei der Folge. Hallo Nikolaus, schön, dass du da bist. Guten Tag kann ich nur sagen. Ich freue mich, dass ich da sein darf. Ja, finde ich sehr schön. Ich habe dich ja gesehen bei der Testbusters Night von Rudi Grötz, wo ich auch mit dabei war. Ich habe deinen Vortrag gesehen und da saß ich dann mit offenem Mund da. Zum einen die Art der Präsentation fand ich steil und auch die Geschichte,
die du erzählt hast, dein Werdegang. Das war so ein cooles Gesamtbild. Und dann habe ich gesagt, den Nikolaus möchte ich auch bei mir im Podcast haben. Ja und siehe da, nach ein paar Terminverschiebungen haben wir es auch geschafft. Der Winter ist dazwischen gekommen. Genau, Winter und Feiertage und Termine und alles. Naja, aber das ist Daily Business, das sind wir ja schon gewohnt. Umso schöner, dass du jetzt da bist. Da freue ich mich. Und ja,
ich würde gleich mal sagen, starten wir mal auch so mit rein. Vielleicht magst du uns einfach kurz mal abholen, was du jetzt machst, wo du wo du arbeitest, als was du arbeitest und dann lass uns beginnen bei der Geschichte am Anfang. Ja, also meine Introduction mache ich ja sehr gerne. Weil es viele komplizierte Wörter drin vorkommen. Aber ich bin aktuell Test Automation Engineer bei Schrag Sekonet. Eine Firma, die sich vorwiegend mit Brandmeldesystemen und Kommunikationssystemen
befasst. Ich bin jetzt halt im Teil Kommunikationssysteme, das heißt eben so Schwesternrufanlagen in Krankenhäusern, Pflegeheimen, Co. Und meine Aufgabe ist es im Daily Business halt Automatisierungskonzepte, Umsetzungen und vor allem auch Tests zu schreiben, die eben unsere Firmware, also unsere Applikationen und Server-Thematiken überprüft. Möglichst automatisch, weil wir haben einen sehr großen Lastanteil an manuellen Tests aufgrund der
Komplexität, die es halt mit sich bringt, wenn man Hardware testet. Und ja, ich bin es ein aufschwingender Zweig muss man auch dazu sagen. Je mehr Automatisierung, desto entlasteter werden die Menschen. Zumindest ist es bei uns so, weil einfach noch so viel Last da ist. Ja, ja. Das klingt ja jetzt ja total easy peasy, als ob das alles so läuft. Aber das war ja nicht immer so,
oder? Nein, also ich muss dazu sagen, früher gab es auch eine Automatisierung, aber das war mir eine Automatisierung im Sinne von, es gab jemanden, der in XML-Dateien irgendwelche Prozeduren hineingeschrieben hat und dann sozusagen das System beobachtet hat, wie es halt jetzt darauf reagiert. Das war jetzt in meinem Kontext jetzt nicht automatisch, sondern eher semi automatisch, weil die menschliche Komponente einfach absolut 100%
erforderlich war, dass das überhaupt durchläuft. Und auch die Kontrollmechanismen waren, also in meinem Feld zumindest so, dass man sich die Haare raufen konnte, also Tests zu kontrollieren, die Ergebnisse zusammenzutragen und dann auch Fehler draufzukommen, die eigentlich nichts mit dem zu testenden Gerät zu tun hatten. Das war ein, ich glaube mal ein jahrelanger Kampf, bis ich gesagt habe, das reicht. Noch immer manuell, also das hat man alles manuell gemacht.
Ja genau, man hat sozusagen den Play Button gedrückt, aber es gab dann eben manuelle Justierungen, wie zum Beispiel, okay, das hier und da etwas umschalten oder umverkabeln, hier und da Konfigurationen ändern und dergleichen. Und auch extrem viel an Copy Paste Arbeit, die halt manuell verrichtet hat, nur um jetzt eine kleine Änderung mit reinzubringen. Das, diese ganze manuelle Arbeit, die ist mir ziemlich auf die Nerven gegangen. Die war ja auch
geschuldet aufgrund dieses Frameworks, das wir damals hatten. Und das ist einfach, ich sage mal frei heraus, von einem Entwickler entstanden, der halt das gebaut hat, weil er einfach schon so lange dabei war und es gab damals einfach den Bedarf, aber keine wirkliche konkrete Zielsetzung mit,
okay, es soll so und so aussehen, sondern okay, es soll einfach mal funktionieren. Und dann ist das Ding halt einfach leider zu schnell wahrscheinlich gewachsen, was wahrscheinlich auch zu diesem monolithischen Aufbau geführt hat mit, okay, Hauptsache es funktioniert und da noch was dazu bauen, das muss ich auch noch dazu bauen. Und nach und nach hat man wirklich Schicht auf Schicht drüber gelegt, bis das Ganze nur mehr ein Jenga Tower war. Wenn man ein Stück gezogen hat,
musste man hoffen, dass der Turm noch stehen bleibt. Und das war einfach eine jahrelange Entwicklung, die eben nicht state of the art war, weil es einfach problematisch in house entwickelt wurde. Ich glaube aber, das ist so ein typischer Fall. Also ich kann mir jetzt vorstellen, dass viele, die das gerade hören oder sehen, mit Tränen in den Augen da sitzen und so langsam vor sich hin nicken und sagen, ja so ist es bei uns auch. Weil sehr häufig gerade solche
Lösungen, die sind manchmal wirklich eine Lösung für ein akutes Problem. Und dann wird das halt dann immer so an den Bedarf angepasst, hier noch was dazu gebaut, da, da, da und dann wächst so etwas über die Jahre hinaus. Klassisches Beispiel, aber ja, was man häufiger hat ist, das fängt mit so einem Excel an, dann wird das zu viel, dann wird eine MS-Excess-Datenbank draus und irgendwann einmal ist da alles drinnen, was man so an das Wissen hat und keiner kann es mehr irgendwie warten.
Ja, auf jeden Fall. Ist auch ein sehr ähnlicher Prozess bei uns. Es gibt immer noch viele Dinge, wo man sich die Haare rauf nimmt, weil das einfach schon seit 20, 30 Jahren so läuft und es ist einfach schwierig in diesen gerösteten Getriebe da irgendwas noch zu bewegen. Ich würde mal sagen, ich kenne das selber bei mir auch. Immer wenn ich was anfange mit einem Projekt und dergleichen, ist es fast schon, als ob man getrieben ist von der Lernerfahrung, dass man einfach immer was
hinzugibt, weil man dadurch sich auch selber irgendwie steigert und verbessert. Aber man muss auch irgendwie bewusst sich machen, dass man vielleicht einen Moment mal innehält, gibt es da nicht schon was? Hat das nicht jemand anderes auch schon gemacht? Und sich wirklich auch trauen, dass man sich auf diese externen Ressourcen verlässt. Und ich glaube auch dieses Misstrauen manchmal ist ein großer Faktor, weil man sagt, nein, ich kann doch nicht irgendeine Library von
irgendwoher nehmen. Das ist halt, ich baue mir mein Auto auch nicht selber zusammen. Aber viel ist halt in die Richtung auch so gewachsen. Ich denke, das ist ja auch häufig nicht mit böser Absicht oder eigentlich nie mit böser Absicht. Man möchte was weiter, man möchte selber lernen. Man, so wie du sagst, die Gründe, das ist schon nachvollziehbar, aber der Moment ist dann da und man sieht dann, okay, so geht es nicht mehr weiter oder jemand
kommt dazu und sieht das und sagt, puh, so können wir das nicht mehr machen. Und in so einer Situation warst du dann und wie bist du denn das dann rangegangen? Also den Superman-Anzug angezogen? Nein, in erster Linie habe ich mir mal überlegt, okay, also diese Änderung hat einfach
Implikationen gehabt. Das war mir irgendwie von Anfang an bewusst, okay, es ist schwierig, diesem Monolith einfach umzustoßen und zu sagen, ich mache jetzt was Neues, weil alleinstande Anzahl an Testfällen, an Konfigurationen und den Bestandsfällen, die einfach im kontinuierlichen
Daily Business gebraucht wurden. Also war ich so von vornherein schon in der Einstellung, okay, ich brauchte irgendein Agreement mit meinem Team, mit meinen Produktmanagern und Co., um halt einfach zu sagen, okay, wir können jetzt so weiterarbeiten, aber es wird nicht besser oder ich gebe es mir zumindest einen Release oder dergleichen Auszeit, damit ich das richten kann. Das klingt jetzt sehr einfach gesagt, das waren mehrere Gespräche, die wir da involviert waren, von verschiedenen
Richtungen beleuchtet, was uns das bringt und warum man nicht so weiterarbeiten kann. Aber letzten Endes war das die initiale Arbeit, also wirklich Überzeugungsarbeit zu leisten mit, okay, wir müssen uns das anschauen, wir müssen das umarbeiten, damit man mal zumindest die Freigabe hat, das zu tun, weil hätte ich das so als Nebenbei-Projekt gemacht, hätte ich mir wahrscheinlich geredet, also das hat sich dann auch selbst herausgestellt, nachdem die Freigabe erteilt wurde, hat das ja
fast ein ganzes Jahr lang gedauert, bis diese Umstellung vollständig abgeschlossen war. Also es wäre nicht möglich gewesen, ohne dass ich das abgesprochen hätte und ich sage mal so, das ist halt etwas sehr Subjektives, also da kann ich nur den Rat geben, einfach offen zu sein und was mir am meisten geholfen hat, ich habe einfach wirklich praxisnah vorgestellt und gezeigt, so läuft das, das ist das, was ich täglich mache und ich habe wirklich gezeigt, das sind die sechs Dateien,
die ich parallel betrachten muss, das sind die Anzahl an Fehlern, die entstehen nur währenddessen, die im Test Result gar nicht mehr aufscheinen und habe halt wirklich versucht, darzulegen, das Ding ist nicht stabil und wird uns auf lang und breit einfach nur noch schlimmer werden. Das waren dann schon sehr überzeugende Argumente, ich bin jetzt nicht hineingegangen mit, wir brauchen was Neues, sondern eher mit dem Ist-Stand, mit was ich halt erlebt habe, aber das muss man auch
drüber bringen, wie es halt aus meiner Sicht ist und nicht aus deren Sicht ist. Ja, also einfach mal auch den Schmerz aufzeigen, ich glaube das ist ganz wichtig, sagst du was schönes, das ist nicht nur sagen, weil ich glaube in einem Meeting ist das schnell gesagt, ich kann so nicht arbeiten, aber wirklich das einmal zu zeigen, wo der Pain eigentlich liegt und das mal auch vorzuführen, das machen wir ja im Positiven auch, wenn wir ein Review Meeting oder was haben, zeig mal hin,
was wir alles Schönes geschafft haben, aber das auch mal das her zu zeigen, wo ist da eigentlich der Pain, ich glaube das kann schon echt auch was bewirken, diesen Freiraum dann zu erhalten,
sowas auch zu heilen. Ja, im nächsten Schritt war es dann eigentlich recht schön, muss ich sagen, die erste Phase nach der Freigabe war am schönsten, weil da durfte ich halt ein Haufenweise Konzepte erstellen und viele Dinge ausprobieren, also es fing ja auch damit an, dass wir noch nicht gewusst haben, was nehmen wir jetzt eigentlich und wir haben etliche Lösungen verglichen, also wir haben angefangen von eben Lösungen von kommerziellen Seiten, die halt sowas
wie Tests stand eben, die halt ein komplettes Produkt verkaufen, haben das kurz ausprobiert in der Testlizenz und sind schnell drauf gekommen, naja tut zwar was es soll, aber kommen auch nicht mehr weg davon, das war für uns schon okay, da sind wir vorsichtig gewesen, wir haben auch ausprobiert, ob man einfach nicht reguläre Test Frameworks umbasteln können und für unsere Zwecke missbrauchen können, also da haben wir einfach dann das Unit Test Framework hergenommen
und umgebaut, sind aber auch schnell drauf gekommen, okay es ist einfach nicht schön, wenn man jetzt auf der Teste, wo ich ja eben bin, ich ja Systemtester und Integrationstester und jetzt in einem Unit Test Framework da irgendwas zu machen, ist einfach so rein konzeptuell, irgendwie merkwürdig, also quasi dass ich jetzt irgendwelche Unit Tests starte und die laufen da durch, so als ob sie Programmcode testen, aber in Wahrheit kommunizieren sie mit etlichen Geräten,
hat dann irgendwie nicht ganz ins Konzept gepasst. Und nachdem wir das halt so ausgiebig ausprobiert haben, sind wir eigentlich auf das Role-Width Framework fast durch Zufall gestoßen, weil ich mich einfach mal breiter umgeschaut habe mit, okay was ist denn so allgemein ein Test Framework, also ich habe dann wirklich halt versucht auch generische Sachen zu finden, weil ich halt drauf gekommen bin, wenn ich jetzt auf der Programmier-Ebene bleibe mit, okay wir brauchen
C# und irgendwas was mit C# funktioniert, wird es schwierig und als ich diesen Horizont ein bisschen erweitert habe, bin ich halt dann auch schnell drauf gekommen, okay es gibt sowas wie das Robot Framework, ein generisches Test Framework, wo man potentiell eben mit verschiedenen Sprachen arbeiten kann. Dieses potentiell hat dann fast sogar ausgereicht, um zu sagen, okay probieren wir
das zumindest mal aus. Und da habe ich dann aber auch angefangen mit, okay kann ich nicht einfach den C# Code, den wir verwenden, in Python konvertieren, das habe ich dann sehr schnell aufgegeben. Das war noch eine Maintainance Schicht, die brauche ich nicht. Und letzten Endes habe ich dann den N-Robot Server gefunden, also ein weiteres Projekt der Public Domain, das aber leider halt nicht mehr Maintained wurde und habe dann einfach entschieden, okay dann nehme ich mir
das Projekt jetzt und baue das jetzt einfach um. Und das war wahrscheinlich die klügste Entscheidung in diesem Kontext, dass ich gesagt habe, okay wir bauen das um, weil wenn hätte ich jetzt mich darauf verlassen, dass da vielleicht irgendwas anderes noch kommt, weil es nicht gut gegangen ist.
Also ich glaube die Wahrnehmung der Framework hat uns da sehr viel Verbesserung gebracht, weil als ich das zum ersten Mal eben meinen Kollegen dann gezeigt habe, mit so einem wirklich simplen Szenario, war das halt schon ein befreienderes Gefühl, weil sie einfach gemerkt haben, endlich, so quasi so einfach und ich durfte dann während ich diesen Server, also diesen Remote Library Interface Server, den man bei Road Framework braucht, während ich den gebastelt habe, durfte
ich halt monatelang meinem Kollegen zuhören, wie er sich gefreut hat, dass das jetzt anders ist. Also man hat es halt immer so gehört über den Bildschirm hinweg, dass es offensichtlich eine Erleichterung mit sich gebracht hat, teilweise aber auch ein Fluchen, weil man eben viel des alten Codes durchfüllen musste und jetzt portieren musste auf das neue System und da ist man dann auch wieder auf tausend Sachen drauf gekommen, die man wahrscheinlich nicht lesen wollte.
Wenn du da sagst, ihr portiert, also wie war denn die Strategie, das Alter ins Neue zu bringen, habt ihr das quasi neu geschrieben, konntet ihr was wiederverwenden oder wie habt ihr euch generell daran gemacht, dieses alte Ding zu zerkloppen?
Ja, bei uns ist es so, dass wir haben im Grunde zwei Kernprojekte, einst und diese zwei Kernprojekte sind einfach unsere Zweigewerke, die wir haben und jedes dieser Kernprojekte war schon teilweise unterteilt in solche C# Projekte, aber da war das Problem, die waren jetzt nicht so Submodulartig oder Nugget Paket mäßig segmentiert, sondern das war halt einfach ein großer Bau mit Projektreferenzen hier und da und dann wurde das
runterkompiliert in eine Konsolenapplikation. Das heißt, unsere Aufgabe, das stand ich in erster Linie darin, all diese Code-Parteien, also etliche Klassen und also eigentlich die Grundklassen, die in diesen Libraries vorhanden waren, zu finden und zu sagen, ok, jetzt fügen wir eben Baustein für Baustein sozusagen eigentlich von unten vom Jenga Tower den neuen Code-Projekt hinzu und so hat man sich halt quasi durchgehandelt und ist halt drauf gekommen, ok,
das braucht man eigentlich nicht, weil das war nur wegen dieser XML-Schiene und das brauchen wir schon, weil das war eben Funktionalität, die halt mit diesem Treiber da spricht und so hat man, habe ich mich eigentlich, also ich zumindest habe das bei mir so gemacht, mein Kollege hat es vielleicht, kann ich nicht sagen, wie er es genau gemacht hat, aber ich nehme an, es ist in ähnlicher Manier abgelaufen, bin ich halt drauf gekommen, ok, das und das braucht Umbauten und das waren bei
mir halt so Sachen, wo ich hauptsächlich eigentlich versucht habe, in der Programmierarbeit alle XML-Schichten rauszuschneiden. Also das war wirklich, das habe ich in meinem Talk auch gesagt, so ein bisschen wie ein Arzt, der da chirurgisch durchschneiden muss, weil ich musste halt an vielen Interfaces und an vielen Schnittstellen wirklich jedwege Erkennung von, ok, da braucht
es irgendeine Referenz auf das XML wegmachen und durch etwas Neues ersetzen. Ja, da war eigentlich dann die meiste Entwicklungsarbeit drin, weil es hat sich dann einfach gezeigt, das XML war fast wie eine Variante, also es war wirklich wie ein Tumor, der verbreitet in dieser Coldface und das war halt schon lustig, sich dadurch zu arbeiten, aber da ich es, ich hatte ein bisschen einen Vorteil gegenüber meinem Kollegen, weil ich habe das ja zeitgleich mit dem Aufbau dieses Remote Library
Interfaces gemacht, das heißt, ich hatte ein viel besseres Verständnis davon, ok, wie diese Keyword-Hierarchie und -Struktur aussieht, also wie werden die Funktionsaufrufe später dann aussehen und konnte dann auch wesentlich leichter diese Codeanpassungen machen, weil ich halt einfach wusste, ok, wohin kommt, mein Kollege hat da vielleicht, musste sich dann noch länger einlesen, also ich, hat es aber dann auch hinbekommen, also das ist jetzt ein bisschen jetzt beide Bibliotheken,
das sind mittlerweile schon im Robot Framework drin und ich würde mal sagen, bei solchen Prozessen ist das Wichtigste, dass man einfach die Ruhe bewahrt, weil das sind einfach, da darf man sich nicht draus bringen lassen und das sind einfach langwierige Prozesse, weil im Endeffekt haben wir glaube ich ein halbes Jahr refactored, also zumindest bei mir war es fast ein halbes Jahr refactoring, weitere Ausbauten vom Remote Library Interface, wieder refactoring, refactoring und
das war, ja, ist ein langwieriger Prozess, aber man muss auch dazu sagen, ja, ist jahrelanger Code, das dauert dann einfach. Wie habt ihr denn das parallel, also ihr habt euch ja quasi ein Jahr genommen dafür oder ein Jahr war quasi veranschlagt mal für den, für diesen Prozess, jetzt braucht man ja das alte wahrscheinlich die Zeit rum noch weiter, weil das ja auch noch läuft, oder habt ihr
dann quasi so parallel auch das neue schon genutzt oder wie seid ihr, wer habt ihr das gemacht? Also konkret war es so, dass wir, weil wir auf zwei Gewerke aufgeteilt sind und man kann auch sagen, dass der Brandsteil ein der stärkere Businesszweige ist, was so das ich jetzt sozusagen in Kommunikationssysteme gesagt habe, okay, ich brauche von den Release Testzyklen einfach Pause und da muss da aber ein Ersatz her und in dem Fall haben wir einfach beim manuellen Testteam diesen
Ersatz eingeholt, heißt das manuellen Testingteam musste in dem Zeitraum für diese Releases einfach
wesentlich mehr testen, nämlich das vollumfängliche, was sonst nicht dabei wäre bei ihnen. Nicht mit unter leicht, hat auch die Testzeit bei ihnen wesentlich verlängert und auch Stress verursacht, aber das hat mich sozusagen frei gespielt als als Alleinentwickler, womit ich mich eben voll konzentrieren konnte, auf dass dieses Remote Library Interface steht und sobald das Remote Library Interface eben da war und man sagen konnte, okay, jetzt kann man eine Assembl in C# nach der
anderen halt so versuchen da hinein zu bringen, konnte ich eben dasselbige meinem Kollegen eben übergeben, so dass er eben zwischen seinen Release Zyklen an der Library arbeiten konnte. Also mehr oder weniger war ich der Freigespielte und mein Kollege musste halt weiter in seinen Tests und Co arbeiten, aber als eben dann ein Zwischenzeitraum bei ihm frei war, konnte er dann die Portierung weitermachen. Also das ist sozusagen parallel gelaufen, auch einfach weil ich seinen Code nicht
ganz verstehe. Also der Brandsteil meine ich damit, also der ist ein produktspezifisch Teil. Und das war dann auch eigentlich eine sehr gute Parallelität muss ich sagen, weil ich war dann sozusagen der Main Developer von dieser Servergeschichte und hab dann aber auch erst danach, nachdem er bereits seine Library umgebaut hat, meine umgebaut. Das heißt, ich konnte da auch da ein bisschen
Erfahrungen sammeln. Im Grunde war das auch ein großer Glücksfall rein von der Release Zeit her, weil wir auch gerade einfach in einem Zeitraum waren, wo ein Release Paket war, das einfach nicht so extrem groß war. Also es hat gepasst sozusagen. Ich weiß nicht, wie es den mannen und Test Kollegen im Detail gegangen ist bei dieser Aufgabe, aber im Großen und Ganzen war es getrieben durch mich, weil eben ich frei gespielt werden konnte in den Teams. Also wenn ich parallel irgendwas gemacht
hätte, wäre das wahrscheinlich nicht so sauber über die Bühne gegangen. Ja, verstehe. Irgendwann war dann das Jahr dann auch um und wie war denn der Stand? Habt ihr das geschafft in der Zeit? Nein, leider. Es war schon sehr stressig. Also ich bin dann ziemlich in Strauchengen gekommen, als wir eben ein Bussystem hinzubekommen haben und ich eben sozusagen eine neue Protokollebene
implementieren musste. Und dann war ich aber mittendrin im neuen Framework und dann musste ich das halt irgendwie was Neues zu schaffen, war halt damals noch ein schwieriger Zeitpunkt. Und dann hat das wesentlich länger gedauert, diese einfach diesen Integrations Test aufzustellen als gedacht. Und das hat mich auch wesentlich verzutmaß. Also im Großen und Ganzen war es schon
ein Jahr, aber ich muss sagen, die Überlappung war dann nicht nur so leicht festzustellen. Ich habe dann sozusagen ein halbes Jahr, das war das Remote Library Interface und dann ein weiteres halbes Jahr, wo ich mich dann mit meinen Libraries beschäftigt habe. Und weil das eben bei mir nachträglich gekommen ist, dann bin ich dann mittendrin in Strauchengen gekommen, weil ich musste dann eben auch noch meine Testumgebung umbauen, also die physische Testumgebung. Ich
musste etwaige einfach dieses neue Produkt hinzubekommen. Für das neue Produkt musste man natürlich auch Testkonzepte erstellen. Das heißt, da war ich dann schon ein bisschen
überbelastet einfach. Das war nicht so schön. Mittlerweile aber haben wir schon wiederum einen anderen Weg eingeschlagen, weil ich gesagt habe, bei diesen ganzen Umbauten ist mir das nächste große Drum aufgefallen, weil ich gesagt habe, okay, mit diesen Hardwareaufbauten, sagen wir das tolle Framework, aber dafür nur ein Viertel dessen, was wir vielleicht testen könnten. Und dann habe ich gesagt, jetzt muss ein neuer großer Hardwareaufbauer dazu und das war dann das
nächste große Ding. Okay, da muss man vielleicht eine eigene Folie mal dazu machen. Ist denn quasi von dem alten noch was da oder habt ihr das wirklich dann auch abgedreht? Weil ich kenne es häufig, dass man dann so, dann ist es schon fertig, das neue, aber man traut sich dann doch nicht beim alten, ja vielleicht brauchen wir das nochmal oder wie habt ihr das mal geschafft, irgendwann den Hebel dann auch umzustellen und sagen, okay, das alte ist jetzt Geschichte?
Für mich war das sehr leicht, weil ich habe eine sehr große Abneigung gegenüber diesem Framework entwickelt in der Zeit, in der ich es verwendet habe. Also war es für mich einfach so von einem Tag um den anderen. Also sobald das funktioniert hat, habe ich nie wieder hingeschaut. Aber das heißt jetzt nicht, dass alles in diesem alten Framework Mist war. Da waren etliche Implementierungen drin, auf die ich weiterhin aufgebaut habe. Also da waren ja auch trotzdem
immer noch Kommunikationsschnittstellen drin, um halt mit Servern und Co. zu sprechen. Da waren Abbildungen, also Klassenabbildungen von etlichen Protokollen drin. All derlei Sachen werden natürlich weiterhin verwendet. Das Wesentliche, was wir wirklich rausgeschnitten haben, war einfach diese XML-Testorganisationsschicht und haben das sozusagen dann einfach aufgebaut auf diesen Framework und sobald das zum ersten Mal funktioniert hat, habe ich nur mehr daran gearbeitet. Bei meinem
Kollege war das anders. Der hatte da ein bisschen noch eine Hin- und Herhupferei, weil er einfach teilweise Sachen vielleicht noch nicht portiert. Man musste trotzdem aber in dem Release-Zyklus einfach die alten Sachen ausführen, was dann einfach zu "Es geht wieder nicht" und so geführt hat. Ich war dann echt zufrieden, weil ich war ja eigentlich der Freie in dem ganzen. Also ich war da ein bisschen gesegnet, weil ich einfach nicht einen Release-Zyklus parallel hatte. Das war natürlich
schön für mich, aber halt mit der Verantwortung, dass das halt auch was wird. Aber ich würde mal sagen, wir verwenden das alte ab sofort eigentlich nicht mehr. Also wir haben jetzt wirklich schon damit abgeschlossen. Es gibt noch ein paar Fälle, wo man sagt, okay, wir müssen da zurück, aber rein aus dem Konzept heraus, okay, wie war das Design von diesem Testfall und wie müssen wir das umschreiben, damit man es mal sieht, aber nicht mehr, um es wirklich aktiv in Tests zu verwenden.
Damit ist es, dass es wirklich gestorben und können wir auch so sozusagen liegen lassen, weil es mit dem neuen einfach tadellos funktioniert. Jetzt kommt natürlich dann der Manager und sagt, so Nikolaus, wie viel sparen wir denn jetzt ein? Was Metriken angeht, da habe ich lang mit mir gekämpft. Ich habe das nicht wirklich quantifizieren können im allgemeinen Kontext, weil das, was man, es war für mich einfach nicht so einfach, weil es waren nicht
protokollierte Probleme in dem Sinne. Das war jetzt nicht so, dass das alte Framework, also das war eigentlich das Hauptaugenmerk, das alte Framework hatte jetzt nichts, irgendwas erfasst, was problematisch wäre. Wenn ich es nicht manuell irgendwie als Bug oder sonst was eingetragen habe,
dann ist das nicht aufgeschieden. Das heißt, das, was wir dann hauptsächlich verglichen haben, um halt zu quantifizieren, dass das besser, schneller und Ding ist, war, wir haben einfach gesagt, okay, schaut euch diesen alten Testfall an und wie viele Codezahlen es benötigt hat,
um gewisse Routinen zu erfüllen und wie viele Codezahlen es benötigen im neuen System. Dann haben wir auch noch verglichen und gesagt, okay, Testdurchläufe haben im alten System so und so lange gebraucht, 20 Minuten, 30 Minuten und wir sind jetzt um x Prozent schneller mit dem neuen System, weil es einfach ein effizienteres System ist. Dann haben wir halt auch noch aufgezeigt, dass es im Potenzial gibt mit dem neuen System, wie zum Beispiel einfach die vorhandenen
Integrationen, die jetzt wegfallen. Also es gibt einfach Integrationen, auch zu zum Beispiel x wave for JIRA, die einfach eingebaut sind, da müssen wir nichts basteln dran. Das war vorher alles Eigenregie und das heißt, es sind einfach viele in dieser Entwicklungsstämme weggefallen, die einfach Zeit freikaufen, gratis und gratis in dem Kontext jetzt. Und dann war das halt schon ein sehr schlagendes Argument, wenn man einfach sagen kann, ja das, was das vorher gemacht hat, ist jetzt
im neuen und wir müssen es nicht mehr entwickeln. Also das ist einfach schon ein sehr befriedigender Punkt, wenn man einfach sagen kann, ja das hat es eh schon eingebaut und ich würde sagen, auch ein großer major selling point von dem Thema war auch das eingebaute Reporting. Weil mit dem olden Framework war Reporting ein Chaos, es war sehr viel manuelle Arbeit, damit man mit dem neuen Framework, war einfach dieses, okay schaut euch mal den Report an und sagt mir, ob ihr das versteht.
Das war dann schon ein so, ja da steht wirklich ein Satz, was das Ding macht. Das ist schon ein sehr guter Punkt, dieses eingebaute Report System. Super, wenn du jetzt nochmal auf diesen Prozess zurück schaust, auf dieses Jahr, auf diese Entwicklung, was sind denn so deine zwei, drei Key-Learnings, die du aus dieser Zeit für dich rausgezogen hast? Geduld bewahren. Also in der ganzen Zeit habe ich mich ja gefühlt, als ob ich auch ein bisschen auf den Naden laufe. Einfach weil ich
gewusst habe, ich habe mir da ziemlich was rausgenommen. Also ich habe mich frei gekauft, aber das war dann schon einfach, okay wenn ich jetzt, wenn das dann nicht funktioniert, dann habe ich Geld verschmissen und zwar nicht wenig. Also war ich so, habe ich ja nicht sehr viel Geduldserfahrung darin gelernt, dass man halt einfach gewisse Dinge ein bisschen hin nimmt und
mit Ruhe an die Sache herangeht. Weil ich habe mich jetzt versucht eigentlich möglichst nicht stressen zu lassen und dadurch sozusagen in neuen Systemen wieder einhudeln und eine schlechte Implementierung zu machen. Das heißt Ruhe und Geduld bewahren, wenn man refactored, ist schon ein wichtiger Punkt, auch wenn es nicht immer möglich ist. Einfach weil man diese Zeit braucht, um etwas Neues aus etwas Alten zu machen. Also das war wahrscheinlich, ich bin ein bisschen
ein geduldigerer Mensch geworden. Weniger aggressiv oder so, also einfach ruhiger im Gemüt, hoffentlich. Ja also ist das neu auch ein bisschen dein Senden-Framework geworden. Ja super, Nikolaus, vielen lieben Dank für diesen Einblick, für das du uns da mitgenommen hast, mal in so eine praktische Transformation, wie du das erlebt hast. Das fand ich sehr spannend, weil ich glaube ganz viele stehen vor so ähnlichem Problem wie du damals und sehen diesen Monolith und denken sich,
was jetzt? Also das finde ich schön, dass du mal ein positives Beispiel gebracht hast, wie man sowas auch lösen kann, auch wenn mit Schmerz, aber doch da auch durchgehen kann. Und wir werden dich auch verlinken unten in den Show Notes, vielleicht der eine oder andere da noch dich als Seelengrößter holen für seine Ideen. Wir würden mich freuen. Ich versuche ja auch gerade zum Beispiel privat eben dieses Remote Library Interface Open Source zu stellen, um halt sozusagen dem .NET Core ein
wahrhaftiges Remote Library Interface zu geben, eben fürs Robot Framework. Also da würde ich mich natürlich über Unterstützer freuen, die was da auch super hier. Also wenn sie schafft, dann meldet es euch. Ja, ja sehr schön. Toller Aufruf hier an die Community. Meldet euch bei Nikolaus, vielleicht könnt ihr ihn da unterstützen. Das wäre noch eine schöne Sache, wenn wir das hier noch initiieren können weiter. Super, ich danke dir schön für deine Zeit und ich hoffe, wir sehen
uns bald mal auch in echt irgendwo auf der einen oder anderen Konferenz oder so. Hoffe ich auch, ja. Ja und ich wünsche dir ganz viel Erfolg weiterhin und viel Spaß mit deinem Framework und mit dem was da noch kommt. Machs gut. Tschüss. Ciao. [Musik]