So testest du deine mit KI gebaute App, wenn du noch nie zuvor Software getestet hast
Ein praktischer Leitfaden zum Testen einer mit KI gebauten App, wenn du keinen QA-Hintergrund hast. Wo du klicken solltest, was du absichtlich kaputtmachst und wie du erkennst, wann es gut genug zum Teilen ist.
Du hast eine App mit KI gebaut. Auf dem glücklichen Pfad funktioniert sie — du tippst deinen Namen, klickst den Button, siehst den Erfolgs-Screen. Und jetzt? Ist sie bereit, um an deine drei Beta-Nutzer:innen zu gehen? An dein Team? An deine Kund:innen?
Wenn du keinen Software-Hintergrund hast, fühlt sich Testen wie eines dieser Dinge an, die “echte Entwickler:innen” machen — mit Frameworks und Assertions und CI-Pipelines. Die gute Nachricht: Das ist nicht, was die meiste Testarbeit tatsächlich ist. Die meiste Testarbeit, besonders wenn du etwas Kleines und Neues auslieferst, ist eine Person, die mit Absicht herumklickt. Das kannst du. In diesem Beitrag geht es darum, es bewusst zu tun, damit du die Bugs findest, bevor deine Nutzer:innen es tun.
Das Ziel ist nicht, deine mit KI gebaute App wie ein Profi zu testen. Es ist, sie wie eine paranoide Freundin zu testen, die ehrlich will, dass sie funktioniert.
Der Zwei-Listen-Trick
Bevor du irgendetwas klickst, setz dich zehn Minuten mit einem leeren Dokument hin und schreib zwei Listen.
Liste A — die glücklichen Pfade. Was sind die drei oder vier Dinge, die ein:e Nutzer:in mit dieser App tun soll? Bei einem typischen SaaS könnte das sein: registrieren, das erste Projekt erstellen, eine:n Teamkolleg:in einladen, ein Ergebnis exportieren. Bei einer verzeichnisartigen App: suchen, filtern, einen Eintrag anklicken, ihn speichern. Drei oder vier echte Abläufe, in einfacher Sprache.
Liste B — die unglücklichen Pfade. Was, wenn der oder die Nutzer:in etwas fast richtig macht, aber nicht ganz? Die E-Mail mit einem Tippfehler eingibt. Mitten im Ablauf den Zurück-Button drückt. Zwei Tabs öffnet und in beiden dasselbe bearbeitet. Ein leeres Formular abschickt. Den Inhalt eines Word-Dokuments — Formatierung und alles — in ein Textfeld einfügt. Den Laptop zuklappt und zehn Minuten später wieder aufklappt. Versucht, eine:n Teamkolleg:in mit einer E-Mail-Adresse einzuladen, die schon im System existiert.
Die Glücklicher-Pfad-Liste ist das, worauf dein KI-App-Builder optimiert hat. Es ist, was die KI im Kopf getestet hat, während sie den Code schrieb. Die Unglücklicher-Pfad-Liste ist da, wo die Bugs wohnen, denn fast niemand — nicht die KI, nicht du beim Prompten — hat an diese Fälle gedacht.
Wenn du tatsächlich testest, geh erst Liste A durch, um zu bestätigen, dass die Basics funktionieren. Verbring dann den Großteil deiner Zeit mit Liste B. Liste B ist da, wo der Wert liegt. Liste B ist auch da, wo du herausfindest, was du eigentlich willst, dass die App tut, wenn etwas schiefläuft — was oft ein klärendes Gespräch mit dem KI-Builder erzwingt (“wenn das Formular halb ausgefüllt ist, soll es warnen oder automatisch speichern?”).
Drei Dinge, die du absichtlich kaputtmachst
Sobald du deine Listen hast, sind hier drei Kategorien, die die Mehrheit der echten Bugs in mit KI gebauten Apps abfangen.
Leere und seltsame Eingaben. Schick das Formular ab, ohne etwas auszufüllen. Schick es mit einem ausgefüllten Feld ab. Schick einen Namen ab, der 500 Zeichen lang ist. Schick einen Namen mit Emoji ab. Füg eine URL in ein Feld ein, das einen Namen erwartet. Probier das E-Mail-Feld mit “test”, mit “test@”, mit “test@example”, mit der Adresse “a@b.co” — akzeptiert es legitime kurze E-Mails? KI-App-Builder bauen oft eine Validierung ein, aber die Validierung kann in beide Richtungen falsch sein — zu streng (lehnt echte Nutzer:innen ab) oder zu lax (akzeptiert Müll).
Rückwärts und seitwärts gehen. Die meisten Apps funktionieren prima, wenn man sie wie eine brave Reisegruppe durchläuft. Sie brechen in dem Moment, in dem jemand erkundet. Klick den Zurück-Button. Klick wieder vorwärts. Lad die Seite mitten im Ablauf neu. Öffne dieselbe Seite in zwei Tabs und bearbeite in beiden. Logg dich aus und wieder ein. Wenn du einen “Rückgängig”-Button hast, klick ihn dreimal hintereinander. Das sind keine Sonderfälle. So nutzen echte Menschen Software.
Die Daten danach. Bau das Ding, das deine App baut. Ein Projekt, einen Beitrag, einen Datensatz, was auch immer. Komm dann morgen zurück. Ist es noch da? Hat die Formatierung überlebt? Wenn du es bearbeitest, wird die Bearbeitung gespeichert? Wenn du es löschst, ist es tatsächlich weg, oder kommt es zurück, wenn du neu lädst? KI-App-Builder treffen oft den “Erstellen”-Ablauf und vergessen, dass alles, was du erstellst, bestehen bleiben und später bearbeitbar sein muss.
Wie “gut genug” aussieht
Du wirst deine mit KI gebaute App nie bis zur Perfektion testen. Software ist zu verworren und deine Zeit zu wertvoll. Die Frage ist nicht “ist sie perfekt” — sie ist “ist sie gut genug für die nächste Gruppe von Leuten, vor die ich sie stellen werde”.
Hier ist eine grobe Hierarchie, die du dir leihen kannst.
Gut genug für eine Demo: Der glückliche Pfad funktioniert ohne Absturz. Buttons gehen dahin, wo sie sollen. Du kannst eine Bildschirmaufnahme zeigen, ohne etwas herauszuschneiden.
Gut genug für wohlgesonnene Nutzer:innen: Die unglücklichen Pfade verlieren keine Daten. Formulare sagen dir, was nicht stimmt, statt still zu scheitern. Die Seite neu zu laden macht nichts kaputt. Drei Freunde können es nutzen, ohne dir wegen Hilfe zu schreiben.
Gut genug für zahlende Nutzer:innen: Die App kommt mit Nutzer:innen klar, die du nie getroffen hast. Ihren Browsern, ihren Daten, ihren Gewohnheiten. Du hast eine Möglichkeit zu sehen, wann etwas kaputtgeht (einfaches Error-Tracking reicht — du brauchst kein schickes Dashboard). Du kannst Fehler beheben und neu deployen, ohne die Leute, die es schon nutzen, kaputtzumachen.
Die meisten Builder liefern auf dem “wohlgesonnene Nutzer:innen”-Niveau aus und rüsten dann auf, wenn Feedback reinkommt. Das ist richtig. Der Fehler ist, von “gut genug für eine Demo” direkt auf “gut genug für zahlende Nutzer:innen” zu springen, ohne den Zwischenschritt. Wohlgesonnene Nutzer:innen finden Dinge, die echte Nutzer:innen finden würden — aber sie ärgern sich nicht darüber. Nutz diese Lücke.
Wann du die KI bitten solltest, für dich zu testen
Dein KI-App-Builder kann beim Testen helfen, aber du musst konkret sein, was du willst. “Füge Tests hinzu” ist ein schlechter Prompt. Er generiert Code, der wie Tests aussieht und wahrscheinlich besteht, ohne tatsächlich etwas zu prüfen, das dir wichtig ist. Die meisten dieser automatisch generierten Tests bestätigen, dass 1+1 immer noch 2 ist.
Ein besserer Prompt: “Ich habe gerade versucht, das Anmeldeformular mit einem leeren E-Mail-Feld abzuschicken, und es ist abgestürzt. Find, wo das behandelt wird, und füge eine Prüfung hinzu, die stattdessen einen freundlichen Fehler anzeigt.” Konkreter Bug, konkrete Behebung, konkretes Ergebnis. Darin ist die KI gut. Sie ist schlecht in “stell sicher, dass meine App bugfrei ist”, weil das keine Aufgabe ist — das ist ein Wunsch.
Das andere, worin KI-Builder gut sind, ist, deinen Bug nachzustellen. Wenn du beschreibst, was du getan hast, was du erwartet hast und was passiert ist, kann der Builder den Code meist nachverfolgen und eine Behebung vorschlagen. Die Disziplin, die du brauchst, ist die Disziplin, diese drei Dinge klar aufzuschreiben. Die meisten Bug-Berichte von Anfänger:innen sind irgendeine Version von “es funktioniert nicht”. Die meisten behebbaren Bug-Berichte sind “ich habe X geklickt, Y erwartet, Z bekommen”.
Testen ist Lesen, nicht nur Klicken
Eine letzte Sache. Du musst nicht jede Zeile Code in deiner mit KI gebauten App verstehen, um sie gut zu testen. Aber du solltest zumindest überfliegen. Öffne die Datei, die die KI gerade geändert hat. Lies die Funktion, die sie hinzugefügt hat. Du musst nicht wissen, was jedes Schlüsselwort bedeutet — du musst wissen, ob die Funktion zu tun scheint, worum du gebeten hast.
Viele mit KI gebaute Bugs sind nicht “der Code ist kaputt”. Sie sind “der Code macht etwas leicht anderes als das, was du wolltest”. Ein Feld speichert an den falschen Ort. Ein Button aktualisiert eine Sache, aber nicht die verwandte. Ein “Löschen”-Button versteckt, statt zu löschen. Die fängst du nicht ab, ohne zu lesen, was tatsächlich gebaut wurde.
Behandle den Code als etwas, das du prüfen kannst, nicht als etwas, das du schreiben musst. Das ist der Unterschied zwischen einer mit KI gebauten App, der du vertraust, und einer, von der du nur hoffst, dass sie funktioniert.
Die einfache Version
Wenn du dir nichts anderes merkst: Schreib die zwei Listen, mach Dinge absichtlich kaputt und entscheide, auf welchem “gut genug”-Niveau du auslieferst. Die meisten Bugs in einer mit KI gebauten App sind nicht subtil. Sie sitzen auf der Unglücklicher-Pfad-Liste, die sich niemand aufzuschreiben bemüht hat.
Wenn du eine kleine Hausaufgabe willst: Such dir eine App aus, die du gebaut hast, und probier vier Dinge — ein leeres Formular abschicken, mitten im Ablauf neu laden, einen Datensatz bearbeiten und ihn morgen prüfen, und eine:n Freund:in bitten, es zu nutzen, ohne dass du zusiehst. Was auch immer kaputtgeht, ist deine echte Bug-Liste. Alles andere ist Prokrastination.