Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Reggie und habe euch eine Folge von den Software Quality Days 2024 aus Wien mitgebracht. Was macht man, wenn man eine Software übernimmt und sich diese als Überraschungsei herausstellt? Immer wieder lustige Sachen, die man da drinnen entdeckt, mit denen man nicht gerechnet hat und wo vorneweg gar nicht klar ist, wie es eigentlich um die Qualität steht. Diese Herausforderung
hatten Sonja und Helmut. Was sie gemacht haben, um das Projekt zum Erfolg zu führen, welche Tipps sie für uns haben, das erzählen sie in der heutigen Folge. Und jetzt viel Spaß beim Hören. Hallo Sonja, hallo Helmut, schön, dass ihr da seid. Vielen Dank, wir freuen uns auch. Das ist ja die erste Aufnahme hier bei den Software Quality Days in Wien. Seit quasi heute startet das Programm. Wir haben ja schon ein paar Jahre lang hier in Wien gearbeitet, aber wir haben ja
ein Programm hier im Podcast. Und ich habe mir im Vorfeld ja euren AppStack angeschaut. Ihr macht ja hier auch einen Vortrag und das fand ich ganz spannend, weil zum einen kam das Wort Überraschungsei vor. Das hat mich getriggert. Und zum anderen habe ich mir das so durchgelesen. Da ging es ja darum, dass ihr quasi so eine unbekannte Software übernommen habt und ohne zu wissen, was so drinnen
steckt oder was dann eigentlich noch kommt. Eigentlich hat es der Kunde übernommen und hat dabei Hilfe gebraucht, weil er nicht wusste, wie gut ist die Qualität? Ist das Ding überhaupt wartbar? Ist das managebar? Ja, ja. Kannst du uns da mal reinholen? Worum ging es denn? Was war denn das so für Softwareapplikationen? Ja, also grundsätzlich geht es um einen Anbieter für öffentliche Mobilität, also ich spreche um einen Ticket-Job. Das heißt, es gibt verschiedene Optionen, die man eben im
Ticket-Job hat. Also wer fährt zum Beispiel und ob du mit Hund oder mit Kindern oder mit Frau fährst. Und das halt wie einen neuen Ticket-Job abbilden. Es gibt schon einen bestehenden Ticket-Job, der wurde entwickelt und damit das Produkt wirklich nicht nur die Nutzungsrechte, sondern wirklich das ganze Produkt, der dem Anbieter gehört, musste das eben gekauft werden. Und da war nicht ganz klar, was ist
da alles dabei, was ist alles drinnen, was wo, wie wann, wo. Und wir haben dann sozusagen im Vorfeld einfach einen Experten und einen Entwickler zur Verfügung gestellt, um einmal einen großen groben Blick reinzuwerfen, um einfach mal zu checken, lohnt sich das Ding überhaupt zum Übernehmen oder nicht. Und wir haben dann auch sehr direkte Worte gefunden und gesagt, wir können euch helfen, wir können das auf neue Beine stellen oder in einen guten Rahmen bringen, allerdings mit gewissen
Bedingungen. Ja, und dann war halt ein gewisser Vertrauensvorschuss notwendig, den uns der Auftraggeber da entgegengebracht hat. Und ich bin im Nachhinein sehr froh, dass er es dann hat. Ja, ja. Du sagst, ihr habt das einmal angeschaut und dann noch deutliche Worte gefunden. Was war denn das für ein Zustand? Was habt ihr denn da so entdeckt? Ja, wir hatten ja nur einen beziehungsweise eineinhalb Tage Zeit, um das zu machen. Und das ist bei mehreren tausend Zeilen Code natürlich nicht so lange.
Idealerweise macht man das automatisiert. Gibt es genug Werkzeuge, die das sehr, sehr gut unterstützen, wo man schon einen sehr, sehr guten Eindruck bekommt, wie ist denn der Zustand der Software. Und da auch über gewisse Parameter sehr gut Bescheid bekommt. Sei es jetzt über Wartbarkeit oder Robustheit oder auch Sicherheitsthemen. Auch das ist ja spannend bei einem Ticket-Job, der einen sehr hohen Touchpoint nach
außen hat, also mit viel Frequenz. Und all diese Dinge kann man da relativ gut automatisiert betrachten. Also war relativ viel statische Analyse, höre ich das richtig raus? Es geht viel auch quasi die Code-Struktur, die Architektur da zu überprüfen? Nein, in dem Fall hatten wir auch kein lauffähiges System. Also wir konnten ja schon den Ticket-Job online anschauen und wir bekamen halt ein Stück Code, was wir anschauen dürften. Und das heißt, statische Analyse eben mit so einer
Sonar-Cube oder auch manuell. Aber sonst haben wir in diesen eineinhalb Tagen nicht so viel Zeit gehabt. Ja, ja, okay. Das ist ja auch ein bisschen ein Zeitdruck. Aber das kann man trotzdem ganz gut abschätzen, was da rauskommt. Und dann auf Basis dessen entsprechende Vorschläge arbeiten, was man besser machen kann. Was waren denn so Knackpunkte, die ihr so gefunden habt, wo ihr dem Kunden sagen musstet, da muss man irgendwie ran, das geht so?
An sich der Code, da kann man jetzt wirklich nicht viel dazu sagen, der war nicht so schlecht. Da muss man schon den Leuten wirklich ihre Ehre lassen, das war wirklich nicht schlecht. Was dann bei der Übergabe ein bisschen ein Thema war, dass manche Komponenten, dadurch, dass halt die verschiedenen Verantwortungen gewechselt sind, manche Komponenten erst sehr spät gekommen sind. Oder dass zum Beispiel Dokumentation nicht in dem Maße vorhanden war, wie es wir ursprünglich,
oder beziehungsweise wie es wir als Standard sehen. Und so war es eine gewisse Einarbeitung, die man halt machen musste. Und während der Einarbeitung sind wir halt drauf gekommen, es fehlen gewisse Komponenten oder sie sind nur als Blackboxes, also als Kompilate vorhanden. Und dann überlegst du halt, gut, okay, wir haben ein Zweidrittel der Software in Code vorliegen, aber ein Eintrittel nicht. Was tun wir jetzt? Ja, ja. Deswegen.
Okay. Das war, glaube ich, der Moment, wo erst einmal das Wort Überraschungseig gefallen ist. Ja, ja. Da braucht es ja wirklich ein Vertrauensverhältnis, dann auch zu sagen, das tut man. Wichtig war, dass der Kunde daran geglaubt hat, dass wir da etwas am Ende des Tages, dass ein vernünftiges Produkt in der Hand haben.
Und die ursprüngliche Idee zu sagen, man analysiert den Code und schaut, dass man dann sozusagen ein Refactoring macht, die hat sich ja dann ein bisschen transformiert hin dazu, was braucht der Kunde wirklich jetzt im ersten Schritt. Und ich glaube, da diese Flexibilität zu haben und da auch das Stichwort von der Sonja Vertrauensvorschuss, da für den Kunden auch das Richtige zu tun, das, glaube ich, war sehr essentiell. Sowohl auf Kundenseite, aber auch von unserer Seite.
Ja, weil es bringt ja uns auch nichts, das Geld zu nehmen und dann nachher ein schlechtes Produkt abzuliefern. Ja. Und im Endeffekt, es mussten teilweise direkte Worte gefunden werden von beiden Seiten. Aber wir haben uns da ganz gut zusammengerauft und haben halt den Scope dann so angepasst, dass nachher die bestmögliche Lösung für den Kunden rauskommt in der Zeit, im Budget und haben natürlich auch verschiedene Technologien dann rundherum auch mit einfließen lassen.
Und das ist ja auch ein sehr guter Punkt, weil wir haben ja auch die Möglichkeit, die Technologien zu nutzen, die wir haben. Und das ist ja auch ein sehr guter Punkt, weil wir haben ja auch die Möglichkeit, die Technologien zu nutzen, die wir haben. Und das ist ja auch ein sehr guter Punkt, weil wir haben ja auch die Möglichkeit, die Technologien zu nutzen, die wir haben. Und das ist ja auch ein sehr guter Punkt, weil wir haben ja auch die Möglichkeit, die Technologien zu nutzen, die wir haben.
Und das ist ja auch ein sehr guter Punkt, weil wir haben ja auch die Möglichkeit, die Technologien zu nutzen, die wir haben. Und das ist ja auch ein sehr guter Punkt, weil wir haben ja auch die Möglichkeit, die Technologien zu nutzen, die wir haben. Genau. Jetzt ist es ja so, die habt ihr ja quasi einiges da jetzt auch quasi reingestellt. Und zuerst war ja die Idee, dass das ein Refactoring ist. Ist es dabei geblieben oder? Teilweise. Also wie gesagt, wir hatten ja die fünf Monate.
Wir mussten in gewisser Weise priorisieren, weil ja noch einige Überraschungen aufgedacht sind, indem wir da im Vortrag nochmal genauer darauf eingehen. Aber im Endeffekt, wir hatten ja den Plan, wir analysieren das Ding einmal, dann machen oder begleiten wir eine Migration, also zum neuen Betreiber. Und dann bauen wir das Ding.
Dann bauen wir noch ein paar Funktionen ein, die der Kunde haben möchte, beziehungsweise verändern noch ein paar Dinge, die uns wirklich im Code aufgefallen sind, fügen noch Dokumentationen zu, bessern ein paar Bugs aus. Das war der Plan. Im Endeffekt haben wir sehr viel Zeit auf die Analyse verwendet, weil wir mussten ja das System komplett verstehen. Wir mussten alle Teile finden, aufbereiten, sodass man sie weiterverwenden kann und haben dann auch die Migration selbst durchgeführt.
Das war ursprünglich gar nicht der Plan. Und wir haben auch das Team-Setup nicht so gestaltet ursprünglich, haben aber dann sozusagen, weil wir ein agiles Setup hatten und gut darauf reagieren konnten jederzeit, haben wir das dann so umgestellt, dass wir eigentlich ein paar von den Entwicklern rausgenommen haben, dafür einen zweiten Architekten ins Projekt reingenommen haben, die Migration dadurch, dass es um einen Ticket-Job geht, die dafür keine Downtime haben.
Also sprich, das muss ja mehr oder weniger von jetzt auf gleich funktionieren. Und da war es dann auch so, dass wir wirklich drei Wochen vorher die Migration geprobt haben, also mit allen Live-Daten schon mal alles richtig vorbereitet, weil durch die ganzen Verschiebungen haben wir das auch in der Urlaubszeit machen müssen. Ich meine, wer schon mal eine Migration erfolgreich gemacht hat, weiß, man macht keine Migration in der Urlaubszeit, man macht keine Migration, wenn es draußen heiß ist.
Der menschliche Fehler steigt in das Unermessliche teilweise. Und unser Chef-Architekt war die drei Wochen vor der Migration auf Urlaub. Also die denkbar besten Voraussetzungen für jedes Projekt. Und so haben wir dann einfach gesagt: Okay, der zweite Architekt und der Chef-Entwickler, die beiden proben die Migration, bereiten alles vor. Was wir können. Und dann ist eben der Helmut, unser Architekt, wieder zurückgekommen.
Und wir haben alles nochmal mit ihm durchgeschaut und haben dann alles vorbereitet. Auch alle Entwickler in einem klimatisierten Raum schon in der Früh weg. Essen bereitgestellt. Essen und Trinken ist ja nicht zu unterschätzen. Essen zählt. Ein wesentlicher Erfolgsfaktor. Genau. Haben noch gemeinsam ein paar Team-Building-Sachen gemacht. Also einfach, wir haben eine Gaudi gehabt an dem Tag, muss man auch sagen. Und dann hat er gesagt: Du Peter, wir werden jetzt soweit. Können wir.
Und er hat gesagt: Ja, okay. Wir haben extra einen Dienstag-Auszug. Dienstagmittag. Auch eine eigenartige Zeit eigentlich für Migration. Aber das ist statistisch gesehen der Tag, wo am wenigsten Leute im Ticket-Job sind. Also ist schon geplant alles. Deswegen zweimal planen, einmal machen hilft. Und haben dann, er hat gesagt: Ja passt, ich gehe Mittag essen. Wir haben die Migration angeschmissen. Und er hat gesagt: Ruf mich bitte an, wenn ihr fertig seid.
Ich habe ihn angerufen und er hat gesagt: Warum rufst du mich an? Ich bin gerade beim Mittagessen. Ich habe gesagt: Ja, passt. Ich gehe Mittag essen. Und deswegen zweimal planen, einmal machen hilft. Und haben dann gesagt, ja passt, ich gehe Mittagessen. Wir haben die Migration angeschmissen und er hat gesagt, ruf mich bitte an, wenn ihr fertig seid. Ich habe ihn angerufen und er hat gesagt, warum rufst du mich an? Ich bin gerade beim Mittagessen. Ja, wir sind fertig.
Im Endeffekt fünf Minuten Migration, läuft alles. Das war eine riesen Erleichterung, glaube ich, für alle Seiten. Ich glaube, eben dieses Mindset auch, dieses agile Mindset, war einer der, sowohl auf Kundenseite, aber auch von uns, einer der wesentlichen Erfolgsfaktoren. Und da rede ich jetzt nicht von das, was man gepredigt bekommt oder was immer wieder so vorgelebt wird, sondern richtig ein Mindset, ein agiles Mindset zu haben, um auf gewisse Dinge einfach flexibel reagieren zu können.
Das ist essentiell gewesen. Das wäre jetzt auch meine Frage. Ihr habt ja dann auch mit neuen Überraschungseiern zu tun gehabt, während des Mittagessen. Da tauchen dann Dinge auf, die unerwartet sind. Und da muss man ja mit den Kunden reagieren. Da würde ich einmal fragen, wie habt ihr denn das gehandelt? Es wirkte, dass ihr das alles ganz gut hinbekommen habt.
Aber was waren denn da so die Faktoren, die das dann wirklich auch zum Erfolg geführt haben, dann auch in der Abstimmung und im ganzen Vorwärtskommen? Naja, enge Absprache. Es waren vier Unternehmen beteiligt am Ganzen. Das heißt, man spricht doch ein bisschen öfter. Und einfach sobald irgendwas Neues aufgepoppt ist, dann ist man alle initial informiert. Wieder zusammengerufen, überlegt, was sind die Möglichkeiten, die wir haben.
Haben einfach Szenarien aufgestellt und gesagt, wir haben in einer Situation vier, fünf Szenarien gehabt und jeder hat so das pro contra dazugegeben. Und dann haben wir halt irgendwann auch in den Meetings, man muss halt dann die Entscheidungen auch forcieren, muss man dann sagen, so Leute, wir verlassen diesen Raum jetzt, bevor wir nicht eine Entscheidung haben, weil das kostet sonst nur. Und da haben wir halt einfach zwischendurch hart priorisieren müssen.
Und dann ist es eben so weitergegangen. Man muss miteinander reden. Es bringt nichts, die Sachen zu verschweigen. Und was ich auch als starkes Commitment in der Sache betrachte, ist, der Kunde hat vor ProEx-Start das gesamte Team bei sich mit einem Scrum-Kurs versehen.
Sie wussten schon Bescheid, aber einfach damit sie da mitspielen können, damit wir einfach keinen Reibungsverlust haben beim Austausch, haben die einfach diesen Kurs gemacht und man hat es auch bemerkt, dass wir einfach gewusst haben, wenn wir das sagen, wissen sie genau, was wir meinen. Und einfach die Abstimmung war sehr gut. Aber da sieht man auch ein ganz starkes Commitment vom Kunden, wie das helfen kann, um hier die Dinge tatsächlich zu bewegen.
Ich glaube, das ist ja häufig auch das Problem. Der Kunde sagt: "Macht ihr mal!" Und wir helfen da so ein bisschen mit. Und dann gibt es da so ein paar Halbtagskräfte, die das dann so ein bisschen unterstützen. Aber es fehlt halt einfach die Abstimmung und die Integration. Aber von Kundenseite sogar da zu agieren und zu sagen: "Okay, wir bilden mal meine Leute aus, damit die auch immer die gleiche Sprache sprechen." Das ist ja schon was Besonderes. Super. Ganz toll. Absolut. Ja, muss man sagen.
Gab es denn auch so Momente, wo wirklich, also so richtig dann die Leute, wo dann die Krise da war, wo ihr gesagt habt: "Was soll man jetzt noch machen? Schon wieder so ein Ding?" Ja, der war tatsächlich ganz am Anfang eigentlich. Oder fast ganz am Anfang. Da haben wir bemerkt, dass eben Doku nicht so ist, wie wir es uns vorgestellt haben. Teilweise der Code noch nicht zugeliefert war. Und wir gesehen haben, das geht sich mit Zeit und Budget vorne und hinten nicht aus.
Für den Kunden natürlich ein riesen Druck, weil da hängen noch mehrere Projekte dran. Weil das Projekt ist ja nur ein Projekt in einer ganzen strategischen Reihe von Projekten. Und das hätte ja alles verzögert. Das hätte den Budgetrahmen gesprengt. Und dann ist man halt vielleicht auch nicht immer mehr so gelassen, wie man sonst ist.
Und wir auf unserer Seite haben gesagt: "Okay, entweder wir brechen das Projekt jetzt ab, weil wir müssen ja natürlich auch klar sagen, wenn wir keine Erfolgschancen mehr sehen, dann müssen wir das sagen." Und da haben wir halt viel herumgeredet. Da sind ziemlich zwischendurch die direkten Formulierungen auch geflogen.
Hat uns aber gut getan, weil wir haben uns einfach direkt ausgesprochen und haben die Dinge, die Situationen, die Szenarien offen auf den Tisch gelegt und haben gesagt: "Wenn wir das machen, kommen wir dorthin. Wenn wir das machen, kommen wir bis dorthin. Und wenn wir das machen, kommen wir bis zum Ende. Aber wir müssen das dann so genau so machen, wie wir es jetzt gesagt haben."
Ich glaube, das ist ja auch ein Punkt, den man ja in so Abstimmungen ja häufig auch vermisst, dass da einfach eine Ehrlichkeit da ist. Wie sehen die Optionen aus, die man hat? Ganz wichtig. Ganz wichtig. Also diese Transparenz. Ich sage immer, da sind ganz wesentliche Elemente eines Erfolgs von, was wir schon gesagt haben, agiles Mindset, Kommunikation, ganz wichtig. Aber auch Transparenz und Ehrlichkeit. Es bringt nichts, über irgendein Information-Hiding zu machen. Irgendwann ploppt es auf.
Das ist völlig sinnlos. In den denkbar ungünstigen Momenten wahrscheinlich. Ja, meistens. Insofern Dinge auf den Tisch legen, so früh wie möglich und dann auch reagieren. Ja, ja. Und das glaube ich, wie gesagt, das sind Faktoren. Hat gut funktioniert in dem Fall, ja. Man muss auch sagen, es waren auch beide Seiten super begeistert einfach insgesamt und beteiligt. Weil oft, wie du sagst, sagt man: "Ja, mach einmal."
Am Endeffekt, uns interessiert das Projekt, weil wir ja sehr neugierig sind und sehr wissbegierig sind, was so Sachen betrifft. Und einfach gesagt haben: "Okay, wenn da jetzt ein Überraschungsei auf uns zukommt, dann nehmen wir die Chance natürlich." Weil wie oft setzen wir ein neues System auf, auf die grüne Wiese? Ja. Öfter. Aber wie oft haben wir die Gelegenheit, wirklich etwas so auszupacken und so ein bisschen eine Challenge zu haben und zu sehen, was ist da eigentlich alles drinnen?
Ja. Und für uns war das halt die perfekte Gelegenheit, weil Helmut ist ja im Testing sehr stark verankert. Ich komme mehr aus dem Projektmanagement, aus der Automatisierung. Und da konnte man einfach alles Know-how, was wir da im ganzen Team auch haben. Weil wir haben da einen App-Entwickler drin gehabt, wir haben verschiedene Cloud-Technologien drin gehabt. Wir haben einfach sehr viel Know-how von verschiedenen Sachen.
Wir haben sehr viel Know-how von verschiedenen Ecken auf gleichem Level sozusagen in einen Topf geworfen und haben das Beste daraus gemacht. Das ist auch etwas, was uns als Unternehmen grundsätzlich auszeichnet, dass wir sehr, sehr breit aufgestellt sind. Also wir kennen quasi wirklich viel. Ja gut, das ist ja in interdisziplinären Teams auch super, weil man sich da auch dann gegenseitig einfach unterstützen kann. Also das Austauschen einer Kompetenz durch eine andere, das ist möglich.
Und auch das war wieder einer der Erfolgsfaktoren, auch da hier zu reagieren. Wenn ihr jetzt auf das Projekt schaut, das ja dann irgendwann einmal auch soweit fertig wird, die Migration, die Mittagspause abgeschlossen hat, dann auch vielleicht ein paar Tests oder sowas. Was war denn für euch die Top 1, 2 Learnings, die ihr jetzt fürs nächste, wenn ihr wieder in so einer Situation seid, mitnehmt? Wo ihr sagt, das werden wir ja künftig im Vorfeld noch besser machen.
Also ich glaube, dass wir uns ja mit diesem agilen Mindset und dem Strukturieren vorgehen aus dem ganzen Testing, weil wir eine Vollzeit-Testmanagerin auch dabei gehabt haben, was ja eher unüblich ist bei Entwicklungsprojekten, weil meistens sagt man ja, okay, wir nehmen einen halben Test dann jetzt auf die Hand. Aber wir haben da auch eine Vollzeit-Testmanagerin dabei gehabt, die da einfach strukturell viel vorgegeben hat.
Und ich glaube, es ist für das nächste Projekt wichtig, auch wenn man glaubt, zu wissen, wie das Projekt sich gestaltet, dass man das Team-Setup möglichst divers gestaltet. Weil da mussten wir schon umstaffen dann zwischendrin. Wenn wir bemerkt haben, das Projekt entwickelt sich in eine andere Richtung, mussten wir das Team bis zu einem gewissen Grad ändern. Ja, das ist nämlich spannend. Ich bin jetzt im Testing seit weit über 20 Jahren. Und eines ist eine Konstante, die sich durchzieht.
Das erste, wo gespart wird, ist das Testing. Hilft aber nicht, sondern ganz im Gegenteil. Macht es meistens komplizierter und teurer. Und das ist durchaus eine Message, die man auch mitgeben kann, dass man in einem Entwicklungsteam, dass Entwicklung jetzt nicht Coding bedeutet oder nicht nur, sondern dass es da ganz andere Disziplinen auch braucht, von Requirements Engineering, Testing und alles das bringt Mehrwert. Und hilft dann am Ende des Tages.
Und hilft dann am Ende des Tages, ein Projekt erfolgreich abzuschließen. Also all diese Disziplinen, nicht alleine das Coding. Genau. Ich glaube, du hast ja vorher unter dem agilen Mindset gesagt, da gehört ja auch ganz viel dazu, dieses Interdisziplinäre und dieser Austausch auch dann. Also nicht nur die Silos zu haben, sondern das auch zusammenzubringen. Ja, super. Sonja Helmut, vielen lieben Dank für diesen Einblick in so ein Erfolgsprojekt auch.
Ich wünsche euch noch ganz viel Spaß bei den Software-Quality-Days. Einen tollen Vortrag dann. Danke. Und noch eine schöne Zeit. Vielen Dank. Hat uns gefreut. Danke. Hat Spaß gemacht. Untertitelung des ZDF, 2020