Was eben noch so im Code stand: Was ich bei KI-gestützter Softwareentwicklung über Regressionstests gelernt habe

Ein Testautomatisierungsingenieur baut nebenbei zwei Apps – und lässt die KI programmieren. Das funktioniert erstaunlich gut. So gut, dass irgendwann ausgerechnet das Testen ein wenig zu kurz kommt. Eine persönliche Geschichte über Tempo, Vertrauen und darüber, was KI-gestützte Softwareentwicklung mit Regressionstests zu tun hat.

„Hallo, ich bin Lorenz Theuer und seit 7½ Jahren Testautomatisierungsingenieur und Softwaretester.“

Außerhalb meiner Freizeit bin ich außerdem Vater einer Tochter in einem Kindergarten mit Elterninitiative. In meinem anderen Job bin ich somit Teil der „Mediengruppe“. Neben E-Mail-Verteiler verwalten und Router an- und ausschalten dachte ich mir irgendwann: Ich baue mal eine App.

Warum? Im Falle einer Notbetreuung verschickte der Kindergarten E-Mails an die Eltern und zog anschließend kleine Zettel aus einer Vase.

True Story und viel Arbeit. Prozessdigitalisierung musste her.

Die Eltern-App in der Praxis: Für mehrere Kinder kann der Betreuungsbedarf separat gemeldet werden.

Eine App hatte ich noch nie entwickelt, und wir brauchten gleich zwei. Dazu ein Backend mit Kindergarten-Eltern-Level-Security. Denn am Ende sollte es eine Pflicht-App für alle Eltern werden.

Also fragte ich Chatty nach einem geeigneten Tech-Stack: Flutter, Dart und Firebase.

Wie schwer konnte das schon werden? Es gab ja nun generative KI, die für mich programmieren konnte.

Ein Jahr später war das Backend fertig und beide Apps in den passenden Stores veröffentlicht.

Und natürlich hatte ich keinen einzigen automatisierten Test geschrieben.

Das mache ich schließlich schon beruflich.

Wie schwer konnte das schon werden?

Da ich weder mit Flutter, Dart, Firebase, Firestore noch Cloud Functions einen Hauch von Erfahrung hatte, ließ ich mich beim Aufbau meiner gesamten Entwicklungsumgebung zum Automatisierungstool degradieren.

Die ersten Meter des Projekts gestalteten sich dadurch tatsächlich angenehm entspannt.

In meinen ersten Refinement-Sitzungen mit Chatty stellte sich bald heraus: Modellbildung konnte mir die KI nicht abnehmen.

Oder besser: Meine Prompts wurden schnell länger und genauer und bekamen bald mehr die Form echter Akzeptanzkriterien als die von Chat-Nachrichten. Und ich musste immer seltener zurückrollen.

Das Domainwissen lag ja bei mir.

Dass Kinder Eltern haben und Eltern auch mehrere Kinder, durfte ich nicht voraussetzen. Aus Domainwissen wird Softwarelogik: Auch die Behandlung von Geschwistern muss explizit modelliert werden.

Die Ergebnisse der Arbeit an der aus dem Modell entstehenden Architektur wiederum erwiesen sich als robuster, und ich konnte wieder etwas unpräziser werden. Auch die GUI-Entwicklung funktionierte spätabends noch prima.

Noch etwas fiel mir auf: Ich konnte zwar keinen Dart-Code schreiben, aber mit meiner Erfahrung in anderen Programmiersprachen konnte ich ihn lesen und zu einem großen Teil auch direkt verstehen.

Damit endete die Feedback-Schleife nicht erst beim Test in der laufenden App. Mein MicroMaster in Software Development und meine ganze Programmiererfahrung waren also keineswegs nutzlos geworden, nur weil die KI jetzt den Code schrieb.

Ich hatte alles im Griff

Also ging es fröhlich weiter: Anforderungen sorgfältig in Prompts sortieren, bauen lassen, deployen, testen, anpassen, glücklich, von vorn!

Ein ungewohntes Tempo kam auf. Nach zwei Videocalls mit dem Vorstand, Feature gebaut. Telefonat mit der Kita-Leitung, Feature raus. Mein Projekt wuchs und wuchs in alle Richtungen.

Wenn meine manuellen Tests der aktuellen Änderungen erfolgreich waren, dann reichte mir das.

Es entstand kein festes manuelles Regressionstestset und auch kein automatisiertes.

Warum, mag der Leser sich nun fragen? So etwas sollte mir doch leicht von der Hand gehen.

Aber die Funktionen waren sehr atomar, potenzieller finanzieller Schaden null, die GUI ständig im Fluss. Da hätte ich laufend Tests anpassen müssen.

Und das Wichtigste: Größere Fehlleistungen der KI durfte ich bis hierhin noch nicht am eigenen Leib erfahren.

Und ich hatte alles im Griff.

Der Tag, an dem ich mit Tests hätte anfangen sollen, kam.

Und ging an mir vorüber.

Es fing an mit Syntaxfehlern durch falsch gesetzte Klammern und Kommata in den größeren Dart-Dateien. Sie ließen sich ohne meine Mithilfe nur durch konsequentes Auslagern von Code in andere Dateien beheben.

Dann war auf einmal ein Button in der GUI verschwunden.

Natürlich genau dort, wo ich länger nicht mehr unterwegs war.

Auf Anfrage kam dann:

„Ich habe den Verlauf geprüft. Der Button wurde offenbar im Zuge der Änderungen in Commit 6f78a3c entfernt. Die zugehörige Logik ist in der aktuellen Version nicht mehr enthalten. Soll ich sie wiederherstellen?“

What?

Sollte das nicht eher andersherum laufen?

Meine Tochter lernt jeden Tag ihre Grenzen kennen. Ich lernte die Grenzen meines digitalen Programmierers kennen.

Ich verlor Zeit, aber nicht den Mut zu meiner Testagenda.

Und so musste ich dann eines Tages feststellen, dass grundlegende Logikanteile aus meiner wichtigsten Cloud-Funktion processLotteryResult auf einmal verschwunden waren.

Die iOS-App war bereits im Store, und mein 14-tägiger geschlossener Android-Pflichttest lief auch schon.

Ich hatte in Produktion immer nur mit einem Kind getestet, da ich auf Notifications, App Attest und Play Integrity fokussiert war.

Das war unangenehm.

Die Funktion, in die alle Eltern und die Kita am meisten Vertrauen haben sollten, wurde unbemerkt entkernt und mein Beta-Test stand vor der Tür.

Ich hatte mich vom Tempo mitreißen lassen.

Mit begrenzter Zeit und dem Ziel vor Augen hatte ich nicht jede Änderung angemessen reviewed und diese Kernsanierung fröhlich durchgewunken.

Dabei wäre es so einfach gewesen. Und in meinem besonderen Fall so naheliegend:

KI-gestützte Regressionstestautomatisierungsstrategie

Riesiges Wort, mäßig mehr Aufwand und eine erstaunlich wirksame Methode, meinen digitalen Programmierer daran zu erinnern, was eben noch so im Code stand.

Klonk!

Aber es gibt auch andere Dinge, die es im Projektverlauf nicht zu vergessen gilt.

Seit ich mein Projekt um eine Produktionsumgebung erweitert hatte, verließ ich mich beim Bauen und Deployen auf die von der KI erzeugten Build-Befehle.

Dass nun aber zwei Flags zu verwalten waren, um Builds Richtung Dev oder Prod auszurichten, entging mir komplett und fiel auch plötzlich meiner KI hinten aus dem Kontext.

Klonk!

Das Ergebnis war, dass mein zweiter von Apple durchgewunkener Store-Build mit defekter App-Attest-Logik für alle zum Runterladen bereitstand.

Getestet hatte ich die Version natürlich schon.

Auf meinem Android-Testgerät.

Das zufällig in Firebase mit einer Test-ID hinterlegt war.

Seitdem lasse ich mir für solche und ähnliche Aufgaben Skripte bauen.

Was einmal geklärt ist, steht damit nicht mehr nur irgendwo im Kontext einer Unterhaltung, sondern im Projekt. Das funktioniert auch prima für andere Erkenntnisse, die nicht offensichtlich im Code stehen.

Und das spart auch noch Credits.

Blumen

Meine Builds laufen jetzt mit Skripten, meine Prompts lasse ich jetzt von einer zweiten KI schreiben und aus unserer verfeinernden Arbeit gleich noch ein Lastenheft.

Und in die Vase dürfen jetzt wieder Blumen.

Diesen Text habe ich im Gespräch mit prüfender Unterstützung von Chatty geschrieben.

Wenn du die englische Version liest, dann war es eher andersherum.

So ist es um mich bestellt.