Wie man eine Anwendung testet, die man nicht selbst geschrieben hat

Eine Anwendung zu bauen erfordert nicht mehr zu wissen, wie sie gebaut wurde. Teams liefern Software aus, die von KI-Programmierwerkzeugen erzeugt, auf Low-Code-Plattformen zusammengesetzt oder von einem externen Lieferanten geliefert wurde. Das Ergebnis funktioniert — bis es das leise nicht mehr tut.

Der übliche Rat lautet, Tests zu schreiben. Dieser Rat setzt voraus, dass Sie die Codebasis gut genug verstehen, um sie zu testen — und genau diese Annahme gilt nicht mehr.

Fangen Sie von außen an

Wenn Sie über das Innere nicht schlussfolgern können, testen Sie das, was Nutzerinnen tatsächlich tun. Nicht „gibt diese Funktion den richtigen Wert zurück“, sondern „kann jemand ein Produkt kaufen“.

Das hat eine nützliche Eigenschaft: Es verlangt überhaupt nicht, den Code zu lesen. Sie müssen wissen, was die Software tun soll, und das wissen Sie mit ziemlicher Sicherheit, weil Sie danach gefragt haben.

Schreiben Sie Ihre wichtigsten Abläufe in normaler Sprache auf:

Eine neue Besucherin kann ein Konto anlegen und sich anmelden.
Eine wiederkehrende Kundin kann einen Artikel in den Warenkorb legen und den Kauf abschließen.
Eine fehlgeschlagene Zahlung zeigt einen klaren Fehler und erzeugt keine Bestellung.
Eine Administratorin kann eine Bestellung finden und eine Rückerstattung auslösen.

Diese Liste ist mehr wert als eine große Suite von Unit-Tests gegen Code, den niemand versteht.

Ordnen Sie Abläufe danach, was ihr Ausfall kostet

Nicht jeder Ablauf verdient dieselbe Aufmerksamkeit. Sortieren Sie nach den Kosten eines Ausfalls:

Umsatzabläufe — alles mit Zahlung, Abonnement oder Kaufabschluss.
Zugangsabläufe — Anmeldung, Passwort zurücksetzen, Berechtigungen. Bricht hier etwas, sind alle auf einmal ausgesperrt.
Datenintegritätsabläufe — alles, was Datensätze schreibt, die Sie nicht leicht wiederherstellen können.
Alles andere.

Decken Sie die ersten drei ordentlich ab, bevor Sie sich dem vierten nähern.

Testen Sie die Fehlerpfade, nicht nur den glücklichen Pfad

Erzeugter Code behandelt den beabsichtigten Fall meist gut und den unbeabsichtigten schlecht, weil der Prompt den beabsichtigten Fall beschrieb.

Testen Sie also, was passiert, wenn die Karte abgelehnt wird, wenn ein Pflichtfeld leer ist, wenn dasselbe Formular zweimal abgeschickt wird, wenn eine Sitzung mitten im Kaufabschluss abläuft. Hier bricht schnell geschriebene Software üblicherweise.

Lassen Sie sie ständig neu laufen

Der Grund, warum das bei KI-erzeugten und Low-Code-Anwendungen stärker zählt, ist die Änderungsgeschwindigkeit. Wenn sich eine Funktion an einem Nachmittag neu erzeugen lässt, ist eine Testsuite, die einmal pro Release läuft, nahezu nutzlos. Was auch immer Sie einsetzen: Die Tests müssen oft genug laufen, um eine Regression an dem Tag zu finden, an dem sie auftritt.

Wohin das führt

Die praktische Hürde ist meist nicht zu wissen, was zu testen ist — die Liste oben ist nicht schwer zu schreiben. Es ist, dass diese Liste in automatisierte Tests zu überführen herkömmlich eine Entwicklerin erforderte, während der ganze Grund für die Existenz der Anwendung war, dass keine Entwicklerin verfügbar war.

Diese Lücke soll Testmode schließen: die Abläufe oben, geschrieben in derselben normalen Sprache, in der Sie sie gerade beschrieben haben, ausgeführt von synthetischen Nutzerinnen gegen die echte Anwendung, ganz ohne Zugriff auf den Quellcode.