Nić porozumienia

Ból głowy, nudności i potworne pragnienie towarzyszyły z rana Zygfrydowi. Zigi spróbował otworzyć lewą powiekę – skutecznie. Następnie prawą – też skutecznie. Następnie spróbował podnieść się z łóżka, aby spojrzeć na zegarek – nieskutecznie. Kac uniemożliwiał każdy ruch w płaszczyźnie pionowej.

„Więcej nie piję” – skłamał w duchu po raz drugi w tym miesiącu. Takich obietnic składał rocznie przynajmniej dziesięć. Statystyki z wykonania nie były jednak po jego stronie.

Ostrożnie przewrócił się na drugi bok i zrobił głęboki wdech. W sumie wczorajszy wieczór mógł uznać za udany. W końcu udało się wybrać z programistami na wódkę. Po ostatnich ekscesach była to ostatnie droga, która mogła prowadzić do porozumienia. Zigi musiał przyznać w duchu, że nie docenił devsików. Jego obraz typowego nerda, w koszuli, którego jedyną rozrywką jest gra w LoLa zniknął przy trzeciej flaszce. Pozostawało dla niego zagadką, skąd u nich taka mocna głowa.

Wódka nie tylko poprawiała humory, ale i rozwiązywała języki. Udało im się wyjaśnić wszelkie wątpliwości, które mieli do jego ostatnio zgłoszonego błędu. Ustalili też priorytety na następny Sprint i w gruncie rzeczy Zygfryd nic więcej nie pamiętał.

Jedyne co na stałe wyryło się w jego pamięci to obraz dziewczyny jednego z programistów. Laska 10/10. Po prostu śliczna. Pewnie leci na hajs.- Zastanawiał się. W końcu Senior Java Developer musi dobrze zarabiać. Zresztą na co innego miała lecieć? Na kawały o testerach, koszule flanelową czy ilość zdobytych odznak w GTA? Zigi wiedział, że byłby dla niej lepszą partią. W końcu nie raz ratował świat znajdując krytyczne błędy na godzinkę przed wypuszczeniem softu na produkcję. „Kapitan tester” – to brzmi dumnie.

Powoli Zygfryd obrócił się na drugi bok. Ból głowy nie ustępował, chociaż objawy helikoptera jakby osłabły. Ponownie wrócił myślami do wczorajszego spotkania. Okazało się, że testerzy i programiści mieli wiele wspólnego. Oboje mieli kolegów, którzy znali większość gwiazdek porno, lubili jakiś tam sport ( przynajmniej oglądać w TV) oraz jak się okazało – wypić. I to dużo wypić. Jak normalny Polak. Wódkę. Od teraz nigdy już nie powie o nich złego słowa. Po prostu zamiast pisać maila, będzie chodził z nimi chlać. Metoda dobra jak każda inna.

W pokoju rozległ się dźwięk wibracji w telefonie. Pewnie znów coś od niego chcą w pracy. Na szczęście mógł dzisiaj spać ile chciał. W końcu pracował zdalnie.

Zadowolony przewrócił się na plecy zamierzając spróbować chociaż przespać się jeszcze godzinkę. „Kapitan tester” – wybełkotał. „Więcej nie piję” – skłamał po raz trzeci w tym miesiącu, po czym usnął.

Co zrobić z błędami znalezionymi na produkcji?

„Bug happens” – parafrazując słynny slogan. Nasuwa się wówczas pytanie: Co robić? Jak żyć?

Metod reagowania na błędy znalezione na produkcji jest kilka.

Pierwsza to: Olać. Skoro klient nie zgłasza problemów, system działa to po co dotykać czegokolwiek?

Druga: Zwalimy to na drugą firmą, która dostarcza grafikę i powiemy, że to wina layoutów.

Trzecia: Przygotujemy po cichu poprawkę i wrzucimy ją przy okazji kolejnego releasa softu, ale klientowi nie powiemy ani słowa.

Czwarta: Gramy w otwarte karty, klient ma prawo wiedzieć, że w sofcie są błędy. Powiemy co znaleźliśmy, zaproponujemy rozwiązanie , przeprosimy i poczekamy na decyzje. Będziemy proaktywni. To takie modne teraz. I to bez coachingu!

Która metoda jest najlepsza?

Wróżka estymuszka

Są różne metody estymowania czasu, jakie zajmie zrobienie i przetestowanie featurea. Możemy bazować na doświadczeniu, poprzednich projektach, wiedzy, czasu budżetu itp. Mamy nawet Planning pokera, który często wykorzystywany jest w projektach scrumowych.

Po drugiej stronie mamy jednak managerów, dla których wszystko wyestymowane jest źle. Za drogo, za dużo czasu, za dużo ludzi jest potrzebnych. Żeby trafić z estymacją, która zostanie zaakceptowana, trzeba być albo wróżką, albo myśleć jak Manager.

Autentyczna rozmowa między kolegami estymującymi projekt:

[Adam]: Podsumowując, ile czasu Wam to zajmie?

[Marcin]: 4 tygodnie nie damy rady krócej.

[A]: Ok, dobra, to chodźmy do Jarka (Managera), tylko powiedzmy mu, że zajmie to 6 tygodni bo na pewno będzie się pytał, czy nie da się tego skrócić. Pewnie będzie chciał obciąć, więc akurat zostanie tyle ile nam trzeba.

Spotkanie u managera:

[Jarek]: I jak macie już?

[M]: Tak, myślę, że w 6 tygodni damy radę

[J]: Tak długo? Adam, nie da rady tego jakoś zoptymalizować, praca na dwie zmiany, weekend work itp.? Co o tym myślisz?

[A]: Mmm… no w sumie możemy jeszcze coś tam wywalić i jak się chłopaki sprężą to na dwie zmiany powinni dać radę w 5 tygodni.

[J]: Marcin, dacie radę w 4? Macie mocny zespół, pociśniecie i będzie dobrze.

[M]: Adaś to jest realne?

[A]: Noo ostatecznie powinniście dać radę, wpadnij to mnie to pogadamy co i jak zoptymalizować

[M]: No dobra to spróbujemy w 4…

[J]: Super! Dzięki chłopaki!

Wnioski? Wnioski wyciągnijcie sami. Po co komuś scrumy, spotkania, analitycy biznesowi, skoro i tak Manager wie lepiej.

 

Manualny automat.

Zigi zacisnął zęby i z grymasem na twarzy wcisnął przycisk „zrestartuj” na swoim komputerze. Po pięciu godzinach testów i milionie otwartych zakładek w Firefoxie, Windows 10 odmówił posługi. „Już ja im pokaże!” – w myślach motywował się Zygfryd. Ci idiocie (zdecydowanie nadużywał tego słowa w stosunku do współpracowników) znów chcieli pójść w automatyzację, zamiast porządnie przetestować produktu za pomocą testów eksploracyjnych. Na nic zdały się godzinne kłótnie o marnowaniu effortu, nieopłacalności pisania testów dla produktu, który pewnie jeszcze z 10 razy się zmieni. On jedno, Manager drugie. 20 godzin na implementację, 5 godzin na stabilizację w sumie 25 godzin pracy automatyków i testować będzie się „samo”.

Zigi był przeciwnego zdania. Może i w 20 godzin napisaliby test, który sprawdzałby co potrzeba, ale oczywiście testy musiały być pisane „zgodnie z dobrymi praktykami programistycznymi:.

Page Object Pattern.

Czyli jak test na 100 linijek kodu napisać w 500. Ponadto znając specyfikę produktu, wiedział, że testy wysypywać się będą z powodów niestabilnego środowiska. Ale jak zwykle nikt go nie słuchał. Jedyne, co mu się udało wywalczyć to 6 godzin, które mógł poświęcić na przetestowanie produktu aby udowodnić, że sam znajdzie więcej błędów manualnie, niż ten, pożal się Boże, automat.

Po 5 godzinach testów jego lista z błędami była imponująca. Bez tracenia czasu na test plany, test casy i dokumentację, efekty pracy przerosły jego oczekiwania. „Będą poprawiać te bugi przez miesiąc” – uśmiechnął się do własnych myśli. Doświadczenie robiło swoje. Zygfryd wiedział, gdzie należy poświęcić więcej czasu, gdzie kliknąć a gdzie tylko pobieżnie sprawdzić, czy wszystko działa. Jedyne czego miał dosyć, to wypełnianie n-ty raz tego samego formularza, żeby móc przejść do następnej strony. Tutaj honory oddawał automatom, które zrobiłyby to dużo szybciej. Jednak wynik ostateczny mógł być tylko jeden. Automaty wykonują tylko zaplanowane zadania, żaden automat nie wykryje spadku wydajności na trzeciej stronie, po kliknięciu w przycisk „dodaj”. Z tego błędu Zigi był szczególnie zadowolony.

System operacyjny właśnie się włączył. Zygfryd chwycił za myszkę i zabrał się za testy. Z pokoju obok w tym momencie słychać było tylko: „Kur*wa dlaczego to nie działa!”.

„Idioci”- cynicznie zaśmiał się Zigi i kliknął dwa razy w logo przeglądarki.

Pasy (certyfikaty) nie walczą

W Brazylijskim Jiu Jitsu wraz ze wzrostem umiejętności zawodnikowi może zostać nadany wyższy pas, potwierdzający jego wiedzę, doświadczenie i umiejętność zastosowania technik w praktyce. Możliwe do zdobycia pasy to:

  • biały
  • niebieski
  • purpurowy
  • brązowy
  • czarny

Ulepszając swoją technikę oraz zdobywając nowe umiejętności stajemy się coraz to lepszymi zawodnikami. Nominacja na wyższy pas jest ukoronowaniem trudu, włożonego w treningi i z pewnością motywuje do dalszej pracy.

Wśród całej społeczności BJJ znane jest jednak powiedzenie:

Pasy nie walczą.

Oznacza to, że zawodnik z niższym pasem może, bez problemów, pokonać bardziej doświadczonego przeciwnika. Dzieje się tak, ponieważ często zawodnicy są przetrzymywani na niższych pasach (o powody pytajcie trenerów). Innym czynnikiem jest fakty, że niektórzy po prostu nam „nie leżą” i ciężko się z nimi walczy. Poziom w klubach też jest różny, a co za tym idzie umiejętności wymagane na wyższy pas w jednym klubie mogą być nie wystarczające w innym. Nierzadko zdarza się też, że na trening przychodzą zapaśnicy, lub zawodnicy MMA, którzy potrafią pokonać nawet wytrawnego zawodnika.

Podobnie sprawa wygląda z certyfikacją testerów. Organizacja ISTQB oferuje certyfikaty na różnym poziomie zaawansowania, które „teoretycznie” potwierdzają kwalifikacje. Piszę teoretycznie, ponieważ certyfikat ISTQB można zdobyć nie przeprowadzając w życiu ani jednego testu! Czy w takim razie posiadanie certyfikatu ISTQB świadczy o naszych umiejętnościach czy tylko o zdobytej wiedzy?  Podobne pytanie można by zadać zawodnikom BJJ, którzy kupują wyższe pasy przez internet! (tak jest taka możliwość, wystarczy zapłacić i wysłać filmik, na którym wykonuje się techniki)

Co innego jest wiedzieć jak coś zrobić, a co innego zastosować wiedzę w praktyce. Jednym z przeciwników certyfikacji jest James Bach, który uważany jest za eksperta i guru z dziedziny testowania oprogramowania. Nie posiada on żadnego certyfikatu, a jednak  jego umiejętności i wiedza jest ceniona na całym świecie. Takich przykładów można mnożyć. Czy to biały pas vs czarny pas, czy też pojedynek testerski seniora z czterema certyfikatami ISTQB i juniora, który w życiu jedyne co testował to telefon na rozmowie kwalifikacyjnej, wyniku nigdy nie da się przewidzieć.

Czy w związku z tym posiadanie certyfikatu czy też wysokiego pasa o czymś świadczy? To zależy. Najważniejsze jest podejście zdroworozsądkowe i uświadomienie sobie czego tak naprawdę się chce. Sławy, wiedzy, umiejętności, poklasku czy wszystkiego po trochu. .

Dobry tester to teoretycznie dobry wojownik.

Nauka technik w BJJ nie różni się zbytnio od testów w typowym modelu V.

Na początku obserwujesz jak trener pokazuje technikę – to testy dokumentacji, oglądasz i wyłapujesz niuanse, szczegóły techniczne, możliwe wariacje i kontry.

Potem następuje ćwiczenie danej techniki w parach – to testy integracyjne, gdzie próbujesz samą technikę na partnerze, który nie stawia oporu. Powtórzenie za powtórzeniem, aż zacznie wychodzić.

Potem następują testy  systemowe, gdy daną technikę wykonujesz przy oporze przeciwniki, podczas rodizjo bądź walk sytuacyjnych, gdzie łączysz ją z innymi technikami.

Na końcu sprawdzian ostateczny. Testy akceptacyjne, w walce podczas randori. I dopiero wtedy zdajesz sobie sprawę, że Twoja technika jest nic nie warta, gdy twój przeciwnik ma 100kg wagi i wyznaje zasadę „Prawdziwa siła techniki się nie boi”.  Winter is coming…, czas robić masę.

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…

Na ratunek – żona.

Zygfryd nerwowo stukał w klawisze. Już drugą godzinę testował najnowsze wypociny tych głąbów z piętra wyżej zwanych programistami. Nie przepadał za nimi. Otwarcie i z wzajemnością. Rutyną stało się, że co poniedziałek puszczał ten sam test i znajdywał ten sam błąd. „Jak można być takim idiotą i za każdym razem robić te same pomyłki? ” — westchnął w duchu. Co prawda podbijało mu to statystyki, ale miał już tego serdecznie dość.

Tym razem jednak developerzy dali z siebie wszystko. Dwie godziny testów i ani jednego błędu. Nawet głupiej literówki nie udało się znaleźć. Trzy wersje językowe, kilkanaście przycisków i pól do wpisywania tekstów i wszystko działa. Walidacja ilości znaków – działa, obsługa błędów-działa, znaki szczególne, SQL injection, klikanie jak oszalały  kilkadziesiąt razy w jeden przycisk- wszystko działa. Zdesperowany kliknął w przycisk wyślij i przeciągnął go na pole tekstowe. Ku jemu zdziwieniu w polu pojawił się jakiś tekst, „wygląda na link”- pomyślał -„Ale na buga się nie nadaje.”

Bliski rezygnacji, Zigi odepchnął krzesełko, na którym siedział, od biurka. „Potrzebuję przerwy” -powiedział na głos. Z głośników z laptopa leciał muzyka z przypadkowej playlisty. Zamknął oczy i myślami przywołał nową praktykantkę, która wczoraj zaczęła staż w firmie, gdzie pracował. Z letargu wyrwało go głośny i sarkastyczny głos żony.

-Znowu klikasz w te swoje guziczki – powiedziała. – Wziąłbyś posprzątał to biurko, syf taki, że nawet nie masz gdzie myszki położyć.

Tym razem nie zaszczycił żony odpowiedzą. Zrezygnowany westchnął. 10 lat w branży, 3 certyfikaty, doświadczenie w testowaniu mobilek, API, automatyzacja, a jego żona wciąż powtarzała wszystkim dookoła, że jej mąż zawodowo klika w guziczki. Zero szacunku dla człowieka pracy.

Z głośnika zaczęły lecieć pierwsze takty piosenki z filmu „Suicide Squad”.

-Ooo uwielbiam tę piosenkę, dam głośniej! – poinformowała kochająca żona i bez pytania kliknęła na klawiaturze F12, na którym narysowany był głośniczek.

-Zostaw bo zespu…-Zigi zatrzymał się w pół słowa. W momencie, gdy Kasia klikała w przycisk otwarta była przeglądarka Chrom, w której Zigi testował aplikację. To co zobaczył od razu wywołało zmianę nastroju.

-„RESPONSYWNOŚĆ!”

Krzyknął i czym prędzej wrócił do pracy. Po wciśnięciu F12 w przeglądarce otworzyła się strona w widoku jak na urządzeniach mobilnych. „No jasne, jak na to nie wpadłem!”–skrytykował sam siebie w duchu. „Przecież klient coś wspominał, że strona ma się ładnie prezentować, zwłaszcza na nowym Galaxy S7” –pomyślał.

Tymczasem to co zobaczył w przeglądarce to istne testerskie eldorado. Właście żaden przycisk nie był tam gdzie być powinien, a większość tekstów nachodziła to na siebie, to na obrazki.

-Wracamy do gry!- powiedział na głos zadowolony z siebie i z ochotą otworzył Jirę do raportowania błędów.

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…