Anwendungen mit KI erkunden

Anwendungen mit KI erkunden

0:00 Jetzt kommt der Agent ins Spiel — und zwar zunächst in der Rolle, in der er am wenigsten Schaden anrichten kann und am meisten hilft: als Erkunder. Er öffnet die Anwendung, klickt sich durch, notiert, was er sieht. Das klingt harmlos, hat aber eine Tücke, über die wir gleich zuerst sprechen: Ein Agent sieht Verhalten, er kennt keine Absicht.

0:20 Wenn niemand ihm sagt, was richtig ist, schreibt er einfach den Ist-Zustand als Wahrheit fest. Dieses Modul zeigt, wie man aus einer Erkundung brauchbares Material gewinnt statt einer hübschen Zusammenfassung.

Den Testentwicklungsprozess rahmen

0:32 Bevor wir einen Browser starten, klären wir die vielleicht wichtigste Frage dieses Seminars: Woher weiß eigentlich irgendjemand, was in Ihrer Anwendung richtig ist? Diese Frage klingt philosophisch und ist sehr praktisch: Von ihrer Antwort hängt ab, ob eine Erkundung Testfälle liefert oder nur einen hübschen Bericht. Nehmen wir uns also ein paar Minuten für den Begriff, bevor wir Werkzeuge anfassen.

0:54 Der Fachbegriff dafür ist Test Oracle — das Orakel, das entscheidet, was korrekt ist. Ein Bild dazu: Ein Schiedsrichter kann sehen, dass der Ball im Tor liegt. Ob es ein Tor war, weiß er nur, weil er die Regeln kennt. Ein Agent ist in dieser Analogie jemand, der das Spiel beobachtet, ohne das Regelbuch gelesen zu haben.

1:14 Er kann feststellen, dass nach dem Klick eine Meldung erscheint — nicht, ob es die richtige ist. Das Orakel stammt aus Anforderungen, Akzeptanzkriterien und aus den Köpfen der Fachleute. Die Konsequenz ist unangenehm konkret. Ohne Orakel hält der Agent den Ist-Zustand für den Soll-Zustand — und wenn in Ihrer Anwendung ein Fehler steckt, wird dieser Fehler zur festgeschriebenen Erwartung.

1:39 Danach ist er nicht mehr auffindbar, im Gegenteil: Ein Test wacht jetzt darüber, dass er bestehen bleibt. Dazu kommt, was gar nicht erst sichtbar wird: Rabattgrenzen, Fristen, Berechnungen im Hintergrund. Und was nie ausgelöst wird, existiert für den Agenten schlicht nicht. Erkundung liefert also Rohmaterial — wertvoll, aber unbewertet.

2:00 Die entscheidende Information dieser Tabelle steht in der letzten Zeile, und sie ist bewusst als Kontrast gebaut. Die ersten drei Quellen sagen Ihnen, was gelten soll: Anforderungen, Fachbereich, bereits abgesicherte Tests. Die vierte sagt nur, was gerade passiert. Beobachtung ist keine Erwartung — dieser Satz klingt banal und wird trotzdem täglich verletzt, weil beobachtetes Verhalten so plausibel aussieht.

2:24 Praktisch heißt das für uns: Der Agent liefert Zeile vier. Die Zeilen eins bis drei müssen Sie mitbringen, und zwar bevor die Erkundung beginnt. Fünf Minuten Vorbereitung sparen hier eine Stunde Aufräumen. Benennen Sie die Benutzerreise, um die es geht — nicht „schau dir den Shop an", sondern „Kasse mit Gutschein". Formulieren Sie das Risiko dahinter: Was darf auf keinen Fall passieren? Legen Sie Rolle und Ausgangszustand fest, sonst erkundet der Agent die Anmeldeseite.

2:53 Notieren Sie die Regeln, die er nicht sehen kann. Und setzen Sie eine Grenze, welche Bereiche tabu sind — Zahlungsanbieter zum Beispiel. Ein Auftrag ohne Grenzen führt zu einem Ergebnis ohne Fokus.

Eine Webanwendung mit KI erkunden

3:06 Der Rahmen steht. Jetzt schauen wir uns an, wie ein Agent technisch überhaupt einen Browser bedient — und warum er dabei nicht auf Bilder schaut. Sie werden sehen: Was der Agent tut, ist weniger geheimnisvoll, als es aussieht — und genau deshalb kann man seine Schritte nachvollziehen und beurteilen. Wir gehen den Weg einmal von Hand mit, bevor wir ihn abgeben.

3:28 Ein verbreitetes Missverständnis lautet: Die KI sieht den Bildschirm. Tut sie nicht, jedenfalls nicht hier. Sie arbeitet auf einem Accessibility Snapshot — einer strukturierten Liste dessen, was auf der Seite ist: Rollen, Namen, Referenzen. Das ist ungefähr das, was ein Screenreader vorlesen würde. Diese Referenzen benutzt der Agent, um zu klicken und zu tippen.

3:50 Der Vorteil ist handfest: Diese Sicht ist kompakt, eindeutig und ändert sich nicht mit dem Layout. Ob dahinter Playwright MCP oder die Kommandozeile steckt, ist eine eigene Frage — die klären wir in Modul sieben. Diese fünf Befehle sind kein Selbstzweck. Was Sie hier von Hand tippen, macht der Agent später in seiner Schleife genauso: öffnen, einen Snapshot holen, ein Element über seine Referenz anklicken, Konsole und Netzwerk nachschlagen.

4:17 Der Grund, warum wir das einmal manuell machen: Danach können Sie das Protokoll eines Agentenlaufs lesen wie ein Fahrtenbuch, statt es für eine Blackbox zu halten. Und Sie bekommen ein Gefühl dafür, wie viel Information ein einziger Snapshot in den Kontext trägt — das erklärt später, warum lange Erkundungen teuer werden.

4:36 Die interessanten Beobachtungen macht man selten auf der Oberfläche. Ein Beispiel aus unserem Pflanzenversand: Der Gutschein wird eingelöst, die Summe ändert sich nicht, und es erscheint keine Meldung. Auf dem Bildschirm ist nichts zu sehen — im Netzwerk steht eine Absage mit Statuscode 422. Erst diese beiden Informationen zusammen ergeben einen Befund.

4:57 Ähnlich die Konsole: Sie verrät Fehler, die die Anwendung vor der Benutzerin verbirgt. Und der Speicherzustand erklärt, warum ein zweiter Durchlauf plötzlich anders läuft. Zustandsübergänge sind der Ort, an dem die guten Fehler wohnen. Systematisch heißt hier: nicht dem Zufall überlassen, was ausprobiert wird. Erst den Happy Path einmal ganz durchspielen und protokollieren — der ist die Referenz.

5:23 Dann an jeder Eingabe den Fehlerfall provozieren und den Meldungstext festhalten; genau diese Texte brauchen Sie später für Assertions. Dann die Dinge, die echte Benutzer tun und Tests selten: zurücknavigieren, neu laden, abbrechen. Dann dieselbe Reise in einer zweiten Rolle. Und zum Schluss die Trennung, auf die alles hinausläuft: Was haben Sie gesehen, was nur vermutet?

5:46 Vier Fallen, die in der Praxis viel Zeit kosten. Die erste ist die verlockendste: Man lässt den Agenten laufen und schaut nach zwanzig Minuten nach — dann ist der Kontext voll und der Auftrag vergessen. Die zweite ist ein Sicherheitsproblem und kein Stilfehler: Erkundung gehört nicht auf Systeme mit echten Kundendaten. Die dritte kostet Erkenntnis: Screenshots sind hübsch, aber Netzwerk und Konsole tragen die Information.

6:11 Und die vierte erzeugt Gespenster: Reste einer alten Sitzung führen zu Beobachtungen, die niemand reproduzieren kann.

Nach nützlichen Beobachtungen fragen

6:18 Wie gut eine Erkundung wird, entscheidet sich an einer Stelle, die technisch banal ist und trotzdem den größten Unterschied macht: an der Frage, die Sie stellen. Dieser Teil ist der günstigste Hebel im ganzen Modul: Es kostet nichts, eine bessere Frage zu stellen, und der Unterschied im Ergebnis ist enorm. Wir schauen uns ein paar Frageformen an, die sich bewährt haben.

6:39 Ein Auftrag wie „schau dir die Seite an" liefert eine Zusammenfassung. Die liest sich gut und ist praktisch wertlos, weil man daraus keinen einzigen Testfall bauen kann. Fragen Sie dagegen gezielt nach Eingabevalidierung, Rollenunterschieden und Zustandskonflikten — und verlangen Sie zu jeder Aussage einen Beleg — bekommen Sie Material, mit dem sich arbeiten lässt.

7:01 Der Unterschied ist derselbe wie zwischen einem Reisebericht und einem Messprotokoll. Beides ist Text; nur eines davon können Sie überprüfen. Jede dieser Fragen zielt auf eine andere Art von Lücke, und das ist die Logik hinter der Tabelle: Sie fragen nicht nach Informationen, sondern nach Fehlerklassen. Negativfälle, Berechtigungen, Zustandskonflikte — das sind die drei Ecken, in denen erfahrungsgemäß die Fehler sitzen.

7:25 Die vierte Zeile ist allerdings die wichtigste, und sie wird fast nie gestellt: Wo hast du geraten statt beobachtet? Sprachmodelle beantworten diese Frage überraschend ehrlich, wenn man sie ausdrücklich stellt. Ohne sie verschmelzen Beobachtung und Vermutung zu einem gleichmäßig selbstbewussten Fließtext. Belastbar wird eine Beobachtung durch Struktur.

7:46 Verlangen Sie je Eintrag drei Dinge: Schritt, Erwartung, tatsächliches Ergebnis — und dazu die Belegstelle, also Meldungstext, Statuscode oder Konsolenzeile. Lassen Sie Unsicherheiten getrennt auflisten, nicht in den Fließtext mischen. Widersprüche zur Anforderung sollen markiert werden, nicht geglättet; ein Agent neigt dazu, Ungereimtheiten sprachlich zu versöhnen.

8:08 Und sichern Sie das Ergebnis als Datei — der Planner im nächsten Modul kann damit direkt weiterarbeiten, statt die Erkundung zu wiederholen. Auch hier die typischen vier. Zusammenfassungen zu akzeptieren, in denen Beobachtung und Vermutung verschmelzen, ist der Klassiker — sie klingen kompetent. Meldungstexte ungeprüft in Assertions zu übernehmen ist besonders heikel: Wenn die Meldung falsch ist, zementieren Sie den Fehler.

8:34 Randfälle nur benennen zu lassen, ohne sie tatsächlich auszulösen, erzeugt Papierlage statt Erkenntnis. Und den Kontext mit ganzen Seiteninhalten zu füllen ist die teuerste Variante: Sie zahlen für Text, der die eigentliche Anweisung verdrängt.

Prototypen und Wegwerfskripte

8:49 Zum Schluss dieses Moduls ein Zwischending, das viel Spaß macht und trotzdem eine klare Grenze braucht: das schnelle Skript, mit dem man einfach mal ausprobiert. Solche Skripte haben in jedem Projekt ihren Platz. Nur gehören sie nicht in die Testsuite — und diese Grenze ziehen wir jetzt bewusst, statt sie später mühsam zu korrigieren.

9:09 In der frühen Phase lohnt sich ein rohes Playwright-Skript ohne Test Runner: ein paar Zeilen, die eine Reise durchspielen und etwas ausgeben. Das ist Vibe Coding im besten Sinne — schnell, neugierig, ohne Anspruch. Solche Skripte sind Erkenntniswerkzeuge, so wie eine Skizze auf einer Serviette. Der entscheidende Satz kommt jetzt: Sie werden nicht dadurch zu Tests, dass man ein expect hineinschreibt.

9:32 Sie werden zu Tests, indem man sie neu aufbaut — mit eigenem Ausgangszustand und einer Aussage, die man verteidigen kann. Sieben Zeilen, die etwas ausgeben und nichts behaupten — und genau deshalb liegen sie nicht im Testordner. Beachten Sie, was hier fehlt: keine Isolation, keine Fixture, keine Assertion. Das ist kein Versäumnis, sondern der Zweck.

9:54 Sie wollen wissen, was die Anwendung tut, nicht ob sie das Richtige tut. Wenn ein solches Skript später in die Suite wandern soll, ist die ehrlichste Methode, es danebenzulegen und den Test neu zu schreiben. Was hinüberwandert, ist die Erkenntnis, nicht der Code. Die Tabelle ist als Entscheidungshilfe gebaut, und das Muster dahinter lautet: Fragen Sie nach dem Erfolgskriterium.

10:17 Wenn niemand sagen kann, wann dieses Skript erfolgreich war, ist es ein Erkenntniswerkzeug — und das ist völlig in Ordnung. Sobald es eine fachliche Aussage prüft, gehört es in die Suite, dann aber mit allem, was dazugehört: eigener Ausgangszustand, eigene Daten, wiederholbar. Der Übergang zwischen beiden Welten ist eine bewusste Entscheidung. Er passiert nicht nebenbei beim Aufräumen, sonst landen halbfertige Skripte dauerhaft im Testordner.

10:44 Ihre Aufgabe schließt den Kreis dieses Moduls: Nehmen Sie Ihr Erkundungsskript und entscheiden Sie, welcher Teil davon eine dauerhafte Absicherung verdient. Dieser Teil wird zu einem Test, der isoliert und wiederholbar grün läuft — nicht zu einem angereicherten Skript. Das Ursprungsskript bleibt erhalten und wandert in einen Ordner außerhalb der Suite; es hat seinen Zweck erfüllt und darf das auch zeigen.

11:06 Damit haben Sie alles beisammen, was der Planner im nächsten Modul als Kontext braucht: Beobachtungen, Erwartungen und einen lauffähigen Ausgangspunkt.