1000 Fehler, ein Google Sheet und fünf Stunden, die ich nie zurückbekommen werde
Jeder Bug hat eine Geschichte. Die meisten beginnen mit dem Satz: „Auf meinem Rechner funktioniert es.“
Wir haben eine Datenimport-Funktion für ein Lead-Generation-Unternehmen getestet. Die Funktion schien simpel zu sein. Man klickt auf einen Import-Button, lädt eine Tabellenkalkulation hoch und das System lädt die Kontakte. Jeder ging davon aus, dass es funktionierte.
Diese Annahme ist eine Falle.
Tester existieren, um diese Annahme zu zerstören. Der „Happy Path“ lügt einen immer an.
Wenn wir eine saubere Excel-Datei verwendet hätten, wäre der Import erfolgreich verlaufen. Wir hätten in die Mittagspause gehen können. Wir hätten das Feature ausliefern können. Aber ein Kunde hätte den Bug an einem Montagmorgen in der Produktion gefunden.
Das Problem war ein Google Sheet.
Echte Nutzer verwenden keine sauberen Excel-Dateien. Sie nutzen unordentliche Google Sheets. Sie erwarten, dass Systeme mit ihrem Chaos umgehen können.
Als wir die Google-Sheet-Daten hochluden, versagte das System. Wir sahen über 1.000 Fehler. Der Bildschirm füllte sich mit Fehlermeldungen. Derselbe Button und derselbe Datentyp verursachten einen totalen Zusammenbruch, nur weil sich das Quellformat geändert hatte.
Wir kehrten zu Excel zurück, um mehr zu testen. Wir probierten eine Mischung aus gültigen und ungültigen Zeilen. Das System kam damit gut zurecht. Es übersprang die fehlerhaften Zeilen und machte weiter.
Dann probierten wir das Chaos der realen Welt aus. Wir luden eine Massendatei mit hunderten von Zeilen hoch. Die meisten waren Müll. Nur wenige waren gut.
Das System brach komplett zusammen. Die Validierungslogik funktionierte bei ein paar fehlerhaften Zeilen noch, aber unter einem Berg von schlechten Daten brach sie zusammen.
Wir verbrachten fünf Stunden damit, die Ursache zu finden. Wir starrten auf Bildschirme, führten Tests erneut aus und gaben den Dateien, dem Browser und dem Kaffee die Schuld.
Diese fünf Stunden waren billig. Die Alternative wäre gewesen, dass ein Kunde seinen Nachmittag verliert und das Vertrauen in unser Produkt verliert. Für Bugs im Test zahlt man mit Zeit. Für Bugs in der Produktion zahlt man mit Kunden.
Ich werde mich jedes Mal für die fünf Stunden entscheiden.
Ein guter Tester fragt nicht, ob ein Feature funktioniert. Ein guter Tester fragt, wie man es kaputt macht.
Hören Sie auf, wie ein Entwickler zu denken. Fangen Sie an, wie diese Leute zu denken:
- Der faule Nutzer, der das falsche Dateiformat hochlädt.
- Der Chaos-Nutzer mit verbundenen Zellen und leeren Zeilen.
- Der Massen-Nutzer mit 4.000 schmutzigen Datensätzen statt 10 sauberen.
- Der Unruhestifter, der genau das tut, was er nicht tun sollte.
Software bricht bei den Eingaben, die man nicht erwartet hat.
Die „simpelsten“ Features sind oft die gefährlichsten. Der Import-Button, das Suchfeld und das Kontaktformular sehen harmlos aus. Das sind sie nicht.
Wenn ein Feature den Happy Path besteht, machen Sie nicht einfach weiter. Seien Sie die Person, die fragt: „Was passiert, wenn ich die schlimmste Datei hochlade, die man sich vorstellen kann?“
Dann tun Sie es.
Optional learning community: https://t.me/GyaanSetuAi