Warum ich Software auch nach einem grünen Build noch teste

Was ein grüner Build aussagt

Ein Build bestätigt, dass sich die Anwendung erstellen lässt. Ein Typecheck findet bestimmte Widersprüche im Code. Ein Test prüft das Verhalten, das wir ihm vorgegeben haben. Ob ein Mensch auf einem kleinen Bildschirm das Kontaktformular bedienen kann, beantworten diese Prüfungen nicht von allein.

Mit KI lassen sich Änderungen schnell umsetzen. Die verschiedenen Zustände der Anwendung müssen trotzdem zusammenpassen. Für die wichtigen Aufgaben lege ich deshalb fest, was ein Nutzer erreichen soll und woran sich das Ergebnis überprüfen lässt.

494 Pixel Inhalt auf einem 390 Pixel breiten Bildschirm

Beim GitHub-Kalender meldete die erste Prüfung keinen horizontalen Überlauf. Trotzdem fehlte rechts ein Stück. Erst die Messung der einzelnen Elemente zeigte den Grund: Der Kalender war 494 Pixel breit, die Ansicht nur 390 Pixel. Sein Container schnitt den Rest einfach ab.

Die Lösung lag im Raster. Es musste sich auf die verfügbare Breite verkleinern können; die Zellen mussten ihren tatsächlichen Platz berücksichtigen. Danach wurden auch die Grenzen der Kalenderkarte und der Suchvorschläge geprüft. Nur die Gesamtbreite der Seite zu messen hatte nicht gereicht.

Der alte Browser-Tab war noch da

Beim Cookie-Dialog griffen eine alte und eine neue Version des Portfolios auf denselben gespeicherten Eintrag zu. Der alte Code kannte dessen neue Fassung nicht und entfernte sie. Im neuen Tab erschien daraufhin der Dialog erneut. Die gerade getroffene Auswahl war wieder weg.

Änderungen an localStorage werden über das storage-Ereignis auch anderen Tabs derselben Origin gemeldet. MDN beschreibt dieses Verhalten. Der frische Testbrowser hatte die Kombination aus alter und neuer Anwendung noch nicht enthalten.

Die neue Auswahl wird heute getrennt vom alten Format gespeichert. Gleichwertige Entscheidungen lassen sich übernehmen; neue Zwecke erhalten keine Zustimmung aus einer alten Fassung. Auch eine spätere Ablehnung im alten Tab wird berücksichtigt. Der zusätzliche Test hält beide Versionen offen und prüft Neuladen und Widerruf.

Nach dem Absenden weiterprüfen

Bei einer Anfrage reicht es nicht, dass der Absenden-Button reagiert. Stimmen die Eingabegrenzen im Browser und auf dem Server überein? Kommt die Bestätigung an? Steht die Anfrage im Dashboard? Bei einer Buchung gehört auch die spätere Absage dazu.

In meinem CRM müssen beispielsweise E-Mails, Boards und Termine zusammenpassen. In der Content-Plattform führt der Weg von einer bewerteten Idee zur geplanten Produktion. Die einzelnen Komponenten können funktionieren, während an ihrer Übergabe trotzdem etwas fehlt.

Automatische Tests und den benutzten Browser anschauen

Mit Playwright prüfe ich Abläufe unter verschiedenen Voraussetzungen, etwa mit anderer Bildschirmgröße, Sprache oder Touch-Eingabe. Die verlinkte Dokumentation erklärt diese Möglichkeiten. Eine Emulation bildet dabei ausgewählte Eigenschaften ab, nicht jedes Detail eines echten Geräts.

Zusätzlich hilft ein Browser, der schon länger benutzt wird: mit alten Tabs und gespeicherten Einstellungen. Genau dort wurde der Cookie-Fehler sichtbar. Aus einem solchen Fund mache ich anschließend eine wiederholbare Prüfung, damit er nicht unbemerkt zurückkommt.

Die Abnahme zum Projekt passend planen

Ein kleiner Prototyp braucht einen anderen Prüfaufwand als ein täglich genutztes Geschäftssystem. Vor einer Übergabe kläre ich deshalb die wichtigsten Aufgaben und die Folgen möglicher Fehler. Diese Fragen helfen dabei:

• 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?

Mit einem echten Arbeitstag anfangen

Wenn du eine Anwendung entwickeln lassen möchtest, beschreibe mir einen typischen Arbeitstag damit. Wer benutzt sie? Was muss nach einem Klick tatsächlich passiert sein? An diesen Beispielen können wir Umsetzung und Abnahme planen. Das funktioniert auch bei bestehender Software, die an einer bestimmten Stelle immer wieder Schwierigkeiten macht.