Software mit KI entwickeln: Warum ein grüner Build nicht reicht

Jede Prüfung beantwortet eine bestimmte Frage

Ein erfolgreicher Build zeigt, dass sich die Anwendung erstellen lässt. Ein Typecheck findet bestimmte Widersprüche im Code. Ein automatisierter Test prüft das Verhalten, das wir ihm beschrieben haben. Diese Nachweise sind wertvoll, haben aber jeweils einen begrenzten Umfang. Ob jemand auf einem kleinen Bildschirm das Kontaktformular vollständig bedienen kann, muss als eigene Frage geprüft werden.

Wenn ich mit KI an einer Anwendung arbeite, entstehen schnell neue Funktionen und Änderungen. Damit wächst auch die Zahl der Zustände, die zusammenpassen müssen. Zur Entwicklung gehört deshalb, für die wichtigen Abläufe konkrete Abnahmekriterien festzulegen: Was soll der Nutzer erreichen, und woran erkennen wir, dass es funktioniert?

494 Pixel Inhalt in einer 390 Pixel breiten Ansicht

Beim mobilen GitHub-Kalender meines Portfolios meldete eine einfache Prüfung zunächst keinen horizontalen Überlauf der gesamten Seite. Trotzdem fehlte rechts ein Teil des Kalenders. Die Messung der einzelnen Elemente zeigte den Grund: Der Kalender war 494 Pixel breit, während die getestete Ansicht nur 390 Pixel hatte. Ein umgebender Bereich schnitt den überstehenden Inhalt ab und verdeckte damit das Problem für die bisherige Prüfung.

Die Korrektur musste beim Layout ansetzen. Das Raster darf sich auf die verfügbare Breite verkleinern, und die Kalenderzellen richten sich nach ihrem tatsächlichen Platz. Anschließend habe ich auch die Grenzen der Kalenderkarte und der Suchvorschläge geprüft. Die entscheidende Frage war, ob der benötigte Inhalt vollständig sichtbar und erreichbar ist.

Ein Update ersetzt keinen bereits geöffneten Browser-Tab

Der zweite Fall zeigte sich in einem bereits länger benutzten Browser. Ein älterer Portfolio-Tab und die neue Version griffen auf denselben gespeicherten Cookie-Eintrag zu. Der ältere Code kannte die neue Fassung nicht und entfernte sie. Im neuen Tab erschien dadurch der Dialog sofort wieder, obwohl die Auswahl gerade bestätigt worden war.

Das zugrunde liegende Browser-Verhalten ist dokumentiert: Änderungen an localStorage werden über das storage-Ereignis auch anderen Tabs derselben Origin gemeldet. Die unten verlinkte MDN-Dokumentation erklärt diesen Zusammenhang. Ein sauberer neuer Test-Browser hatte die problematische Kombination aus alter und neuer Anwendungsversion nicht enthalten.

Heute liegt die neue Auswahl getrennt vom alten Speicherformat. Gleichwertige Entscheidungen können übernommen werden; eine alte Zustimmung erweitert keine neuen Zwecke. Eine spätere Ablehnung in einem älteren Tab wird weiterhin berücksichtigt. Der ergänzte Test hält beide Versionen gleichzeitig offen und prüft auch Neuladen und Widerruf.

Der Weg nach dem Klick gehört zur Funktion

Bei einem Kontaktformular endet die Aufgabe nach dem Ausfüllen nicht. Stimmen Pflichtfelder und Grenzen im Browser mit dem Backend überein? Kommt die Bestätigung an? Taucht die Anfrage im vorgesehenen Dashboard auf? Bei einer Terminbuchung gehören die verfügbare Uhrzeit, die Bestätigung und eine mögliche Absage zum selben Ablauf.

Diese Perspektive ist auch für interne Anwendungen relevant. Mein Vertriebs-CRM verbindet Boards, Postfächer und Termine. Die Content-Plattform verbindet Themenbewertung, einen Agenten und redaktionelle Planung. Der Nutzen entsteht an den Übergängen: Eine Information muss dort ankommen, wo jemand damit weiterarbeitet. Einzelne erfolgreich geprüfte Komponenten decken diese Übergänge noch nicht automatisch ab.

Wiederholbare Tests und den vorhandenen Browser zusammen nutzen

Für wiederholbare Browserprüfungen nutze ich unter anderem Playwright. Damit lassen sich beispielsweise Bildschirmgrößen, Touch-Eingabe und Sprache simulieren, wie die verlinkte Dokumentation beschreibt. So kann derselbe Ablauf mit verschiedenen Voraussetzungen geprüft werden. Eine solche Emulation bildet ausgewählte Eigenschaften ab; sie ist keine vollständige Nachbildung jedes echten Geräts.

Zusätzlich lohnt sich der Blick in einen bereits verwendeten Browser: mit gespeicherten Einstellungen, offenen Tabs und dem Zustand vor dem letzten Update. In diesem Fall hat genau das einen fehlenden Testfall sichtbar gemacht. Aus dem gefundenen Fehler wird anschließend eine wiederholbare Prüfung, damit er bei späteren Änderungen nicht unbemerkt zurückkehrt.

Was vor einer Übergabe geklärt sein sollte

Für einen kleinen Prototyp und ein täglich genutztes Geschäftssystem braucht es unterschiedlich viel Prüfung. Entscheidend ist, die wichtigsten Abläufe und möglichen Folgen eines Fehlers im vereinbarten Umfang zu berücksichtigen. Für ein Projektgespräch helfen deshalb konkrete Antworten auf diese Fragen:

• Welche Aufgabe muss ein Nutzer vom Anfang bis zum Ergebnis erledigen können?
• Welche Geräte, Sprachen und bestehenden Browser-Zustände sind relevant?
• Was passiert bei ungültigen Eingaben, doppelten Aktionen oder fehlenden Daten?
• Wie wird geprüft, dass eine Anfrage, Buchung oder Änderung tatsächlich angekommen ist?
• Wie erkennen wir einen Fehler nach einem Update, und wie können wir die Änderung zurücknehmen?

Aus einem konkreten Problem wird ein prüfbarer Auftrag

Wenn du eine Website, ein internes Tool oder eine KI-gestützte Anwendung entwickeln lassen möchtest, beschreibe mir einen typischen Arbeitstag damit. Wer benutzt sie, welche Schritte müssen zusammenpassen und wo kostet der heutige Ablauf Zeit? Daraus lassen sich die Umsetzung und ihre Prüfung gemeinsam planen. Auch bei vorhandener Software ist ein konkreter Ablauf, der im Alltag scheitert, ein guter Ausgangspunkt.