Zabawny jak programista

Dzień jak co dzień. Godzina 10, obowiązkowa część każdego dnia – „Scrum”. Programiści i testerzy prześcigają się w chwaleniu czego to nie zrobili i co będą robić dzisiaj. W tym momencie do akcji wchodzi Zbyszek:

„Wczoraj robiłem testy aplikacji na Androidzie i iOSie. Dzisiaj się będę bawił w zmianę orientacji”

No i się zaczęło. Programiści obiecali pomoc w zmianie orientacji, podsyłając odpowiednie linki, teledyski i cenne uwagi dotyczące zmiany płci. Żeby tak Bugi poprawiali w takim tempie i z takim zaangażowaniem . A biedny Zbyszek no cóż…bycie testerem czasami wymaga poświęceń.

Co w LOGACH piszczy?

Posłużmy się ciocią Wikipedią: : Log (inaczej: dziennik, plik dziennika, rejestr zdarzeń) – chronologiczny zapis zawierający informację o zdarzeniach i działaniach dotyczących systemu informatycznego, systemu komputerowego czy komputera.

Innymi słowy, jest to wymysł developerów, który ma ułatwić im życie. Jednak jak wszystko, to jakie logi maja się pokazywać, również trzeba zaprogramować.

Jakież więc było moje zdziwienie, gdy jeden z błędów zgłoszonych przez testerów brzmiał mniej więcej tak:

„Inappropriate word KURWAAAAAAAA in logs”

Faktycznie, po otwarciu można było zauważyć zrzut logów, a wśród z nich linijkę, w której programista odwołuje się do Pani, uprawiającej najstarszy zawód świata. Czy to wołanie o pomoc? Czy akt desperacji? Prawdopodobnie nigdy się nie dowiemy.

Ciekawostką jest, że błąd został znaleziony przez obcokrajowca, pracującego z lokacji poza Polską. Znaczenie słowa poznał, wpisując je w Google translate…

Czy można stopniować krytyczność błędów?

Naprawdę, krew człowieka zalewa. Na środowisku produkcyjnym wychodzi krytyczny bug, trudno, zdarza się. Programiści w pocie czoła szukają rozwiązania, testerzy lecą do szafek po iPhony i zaczynają sprawdzać.

Błędy na produkcji znajdywane są zawsze w godzinach popołudniwych bądź nocnych, kiedy ani developera ani testera nie ma już w pracy. Taka złośliwość rzeczy martwych.

Informacja od klienta: „Macie 4h na poprawienie, albo revertujemy cały feature.” Brzmi groźnie. Pierwsze uruchomienie i faktycznie bug jest. Reprodukowalny 10 na 10 prób. W tym momencie tester zaczyna zadawać sobie pytanie:

Dlaczego nie wyłapałem tego podczas testów?

Ale nie o tym chciałem pisać. Developerzy szybko znaleźli przyczynę i wypuścili fixa. Sprawdzamy, działa. Robimy więc szybką regresję. Po 5 minutach znajdujemy kolejny Bug. Krytyczny. Szybkie zgłoszenie i odpowiedź:

Tego błędu nie poprawimy teraz, bo jest mniej krytyczny niż błąd kliencki.

Mniej krytyczny? Serio, będziemy stopniować krytyczność błędów? Cała teoria testowania legła w gruzach. Fix naprawia błąd na produkcji, klient jest zadowolony, a że dodatkowo mamy innego Criticala, who cares?

Ciekaw jak się stopniuje krytyczność?

Mało krytyczny – bardzo krytyczny – w ch*j krytyczny – zajebi*cie krytyczny?

Bycie developerem to musi być przygoda…