REST in peace

Cytat

Duszność, nadmierna potliwość i skoki ciśnienia, to tylko niektóre z objawów, jakie towarzyszyły Zygfrydowi tego ranka. Na szczęści szybkie zapytanie do wujka Googla dało jednoznaczną odpowiedź: Nigdy nie diagnozuj się przez Internet. Zigi wyjrzał za okno. Gęsta mgła ograniczała widoczność raptem do paru metrów. Temperatura na termometrze też nie napawała optymizmem. Całe szczęście, że dzisiaj pracował z domu. Nikt nie będzie go musiał oglądać jak testuje najnowszy wynalazek developerów. Trzy literki, z którymi nigdy wcześniej nie miał do czynienia. API

Niby nic wielkiego, przecież zrobił solidny research jeśli chodzi o Web Services, API, zapytania RESTowe, Jsony itp., jednak nutka niepokoju dalej pozostała.

-No nic jedziemy z tym koksem- spróbował zmotywować się w myślach, po czym odpalił PC.

Tym razem Windows zdawał się współpracować bez przeszkód. Już po chwili oczom ukazała się standardowa tapeta. Zigi co prawda tęsknił za łąką z wcześniejszych wersji Windowsa, ale dzisiaj nie miał ochoty na kolejną bezproduktywną dawkę narzekania. Z drżeniem serca odpalił przeglądarkę i zaczął wpisywać adres. http://api…someaddress…com/survey….$startDate=2016-01-02&endDay=2016-01-10 …enter! Chwila oczekiwania i błąd 404 wyświetlił się na jedynej słusznej przeglądarce. Zigi pozostał niewzruszony. Nie z takimi problemami sobie radził, a chwilowy brak Internetu, to nie jest problem nie do rozwiązania. Szybka diagnoza: odłączony kabel. Czas naprawy: 30 sekund. Pora na próbę numer dwa. http…api…survey…startdday…enter! Tym razem zapytanie zwrócił dziwny ciąg znaków:

{„value”:92,”success”:true,”error”:null}

Chwila zadumy, zerknięcie do notatek, ponowne przejrzenie maili…chyba dobrze. W odpowiedzi Zigi dostał dokładnie to czego chciał! Ilość osób, które w ankiecie podały, że podobało im się szkolenie. Zygfryd uśmiechną się do swojego odbicia w monitorze. Jednak nie było tak źle. Czas na przerwę. W końcu pierwsze osiągnięcie zostało zdobyte. 15 minut później przyszedł czas na dalsze testowanie.

Tym razem tester sprawdził pozostałe zapytania. Wszystkie zwracały jakiś wynik. No właśnie jakiś… Z tego co pamiętał, wyświetlane wartości pobierane były z bazy danych. Nietaktem byłoby nie sprawdzić, czy to, co wyświetla JSON zgadza się ze stanem rzeczywistym. Szybkie zapytanie do bazy danych: SELECT…FROM, WHERE…enter! Dla tego samego zakresu dat zapytanie zwróciło 164 zamiast 92. Ciekawe…to może oznaczać tylko jedno. BUG! Jego pierwszy błąd, znaleziony na testowanie back-endu! I to w ciągu pierwszej godziny testów. Zigi nie posiadał się z radości. Na szczęście Jira działa jak należy. Szybkie zgłoszenie i można wracać do testowania.

Tym razem Zigi sprawdził zachowanie przy nietypowych zapytaniach: niepoprawny format daty- działa. Data początkowa późniejsza niż data końcowa – działa. Brak daty końcowej – działa.

Dwie godzinki później wstępne testowanie zostało zakończone. Efekt? Jeden błąd. Słabo.

Jednak tym razem tester cieszył się, że znalazł cokolwiek. W końcu to był jego pierwszy raz z API. Zygfryd oderwał wzrok od monitora i przeniósł swoje zainteresowanie na kartkę z wydrukowanymi wymaganiami. Klient chciał dodatkowo testy obciążeniowe. To akurat uciekło mu, kiedy za pierwszym razem przeglądał dokumentację. W momencie poczuł ścisk w żołądku. Powróciły ranne objawy. Zigi zerwał się i czym prędzej poleciał do łazienki. Duszność, nadmierna potliwość i skoki ciśnienia nagle okazały się nie poważniejszymi objawami tego ranka.

 

Syndrom jednej techniki

Każdy z nas ma swoją ulubioną technikę. Jeden dusi trójkątem, drugi wyciąga dźwignię na staw łokciowy, a jeszcze inny nie może żyć bez mataleo (duszenie zza pleców). Podczas walki uparcie dążą aby zdobyć pozycję i wykonać swój jeden ulubiony ruch. Ok, mam to sens na zawodach, gdzie liczy się zwycięstwo. Natomiast na treningu – niekoniecznie. Rozumiem, że trzeba doskonalić techniki, ale naprawdę, czy warto powtarzać w kółko jeden i ten sam schemat? Po pierwsze po paru treningach wszyscy już będą wiedzieć co szykujesz w swoim arsenale technik i nikt nie da się na nią złapać. Po drugie, aby się rozwijać trzeba próbować cały czas czegoś nowego. Powtarzanie w kółko tego samego będzie działać tylko w przypadku nowych przeciwników, którzy Cię nie znają.

W testowaniu mamy na to określenie „paradoks pestycydów”. Polega on na tym, że po pewnym czasie nasze oprogramowanie uodporni się na nasze przypadki testowe i nasze testy przestaną wykrywać błędy. Aby testy były skuteczne co jakiś czas trzeba je zmieniać lub modyfikować. Software, który masz do przetestowania jest Twoim przeciwnikiem. Możesz go pokonać raz i drugi używając swojej ulubionej techniki testowania i wznosząc się na wyżyny testerskich możliwości. Jednak przyjdzie dzień, gdzie Twoje testy okażą się bezużyteczne.

Masz więc do wyboru: Trenujesz i wykonujesz w kółko ten sam schemat raz za razem doprowadzając technikę do perfekcji. Czujesz się niepokonany, dopóki nie okaże się, że ostatni raz odklepałeś miesiąc temu białego pasa, który dopiero pierwszy raz przyszedł na trening.

Alternatywą jest rozwijanie swoich umiejętności. Próbujesz cały czas czegoś innego, doskonaląc siebie jako zawodnika. Testujesz za pomocą testplanów, test casów, analizując wszystko krok po kroku zgodnie z dokumentacją? Może warto spróbować testów eksploracyjnych? Automaty, automaty liczą się tylko automaty! A może jednak warto raz przeklikać wszystko ręcznie? Twoje automaty odkryją spadek wydajności? Wszystkich kończysz duszeniami? Może warto poćwiczyć dźwignie? Jak będziesz trenował i testował zależy tylko od Ciebie.

Przychodzi programista do testera.

W ogromnych korporacjach, gdzie nad jednym projektem pracuje grubo ponad 1500 programistów, nie ma zespołów Scrumowych. Testerzy tworzą osobną grupę, natomiast developerzy, w zależności od technologii formują własne, na które testerzy zgłaszają błędy.

Więc siedzisz sobie w fotelu i testujesz. W pewnym momencie jest i on. Bug o ważności Major. Więc robisz szybką inwestygację, przeglądasz logi, z których nic nie wynika i wystawiasz błąd na tą, co zawsze grupę developerską. Bo przecież ostatnie 20 błędów też musiała ta jedna konkretna grupa poprawić. Ty, co prawda pracujesz w firmie krótko, ale jak wszyscy mówią, żebyś się nie przejmował i wystawiał, to to robisz. Pięć minut później zgłoszenie jest już widoczne, więc zadowolony z siebie idziesz na kawę.

Piętnaście minut później, słyszysz jak ktoś idzie. Jest jeszcze daleko, ale Ty już wyczuwasz złe fluidy. Zbliża się do Ciebie, już wiesz jak się czuł muminek, gdy podchodziła do niego Buka. To developer przyszedł „porozmawiać” o Twoim zgłoszonym błędzie. W pewnym momencie zaczyna mówić. I nie są to teksty w stylu – „Ej wiesz co, chyba wystawiłeś błąd nie na tą grupę co trzeba. Chodź przejrzymy logi raz jeszcze, pokażę Ci, dlaczego popełniłeś błąd.” To jest cierpki i konkretny opierdol. A ty siedzisz skulony i nie wiesz, co zrobić, bo się boisz. Bo to kobieta na Ciebie krzyczy. Czujesz się jakby sam Terminator przyszedł i chciał Cię zabić. Więc grzecznie słuchasz i przytakujesz. Potem przepraszasz i obiecujesz, że już więcej błędu nie popełnisz. Tłumaczysz, że pracujesz krótko i nie masz jeszcze tyle doświadczenia.

Dziesięć minut później jesteś wolny. Fala hejtu rozlała się po całym piętrze a ty spocony masz w końcu chwilę, żeby złapać oddech. Kumple siedzący obok śmieją się z Ciebie, bo takie wizyty to dla nich normalność. W końcu zbierasz się do kupy, bierzesz największych testerskich wymiataczy i razem analizujecie to, co głosiłeś. Czytacie, przeglądacie i chwile później okazuje się, …że miałeś jednak rację! Błąd jest i to w części, którą napisała ta jedna konkretna grupa, na którą go zgłosiłeś. Otwierasz więc zgłoszenie, uzupełniasz analizę, dodajesz nowe screeny i wysyłasz raz jeszcze na grupę developerską. Na wszelki wypadek to samo piszesz w mailu, dodając do odbiorców Twojego oprawcę i jej managera.

Godzinę później sprawdzasz status błędu. In pogress… przewidywany czas naprawy – dwa dni. W tym momencie radość wypełnia Twe serce. Wiesz, że dobrze wykonałeś swoją pracę.  W duchu liczysz, że Terminator przyjdzie Cię przeprosić, ale wiesz, że do tego nie dojdzie. Ty i tak triumfujesz. Kim jesteś? Jesteś zwycięzcą!

Mobilki jak mnie słychać?

Zigi po cichu zakradł się do szafki ze sprzętem. Była godzina 8:01, a od ósmej jest możliwość pobierania sprzętu. Nikt przed nim jeszcze pewnie nie myszkował. Zdecydowanym ruchem pociągnął za uchwyt i otworzył półkę. Jego oczom ukazała się cała gama telefonów. Samsung Galaxy S3, S6, S7, Iphony od 5 do 7, parę Nexusów i LGków. Jego uwagę przykuł jednak Iphone 7 Plus, na którego to właśnie ostrzył sobie zęby. Taki wybór, istny raj dla testera! Klient nie sprecyzował, na jakim sprzęcie chce mieć sprawdzoną aplikację, więc Zigi miał spore pole do popisu. Podniósł Galaxy S7, Iphona 7 Plus i Microsoft Lumie. Tą ostatnią bardziej z ciekawości, jako relikt przeszłości. Obrócił ją klika razy, zważył w dłoni i z szyderczym uśmiechem odłożył na miejsce. Nikt, nie robi aplikacji na Windows Phone’a. Nikt.

Zadowolony z łupów odwrócił się i podszedł do notatnika, gdzie kwitowało się pobrany sprzęt. Był pewny, że jego nazwisko będzie pierwsze na liście. Niestety na pierwszej pozycji widniała Kasia, która pobrała Ipada pro – nieźle. Godzina pobrania: 7:50. „A to jędza!” – wyzywał w duchu Zigi. – „Niby sprzęt pobieramy od ósmej, ale widać znajomości robią swoje. Dobrze, że jego ukochane telefoniki nie zostały zabrane.” Szybko zakończył formalności i wrócił do biurka. Czas zacząć testy.

Jako pierwszy na warsztat poszedł Android. Zigi przytrzymał przycisk parę sekund, jednak na ekranie nic się nie pojawiło. „Znowu ktoś odłożył rozładowany sprzęt” – tym razem swą irytację wyraził już na głos. Później sprawdzi kto wczoraj używał Samsunga i obsmaruje go w mailu. Teraz miał jednak ważniejsze rzeczy na głowie. Wczoraj developerzy wypuścili aplikację zarówno na Androida jak i iOSa. Prosta – raptem kilka ekranów, plus prosty formularz rejestracji. Raczej powinna działać i być łatwa do sprawdzenia manualnego – nie ma sensu automatyzować. Podłączył telefonik do PC i wcisnął ponownie odpowiedni przycisk. Tym razem logo Samsunga rozbłysło na ekranie. Po chwili telefon już był gotowy do testów. Wgranie aplikacji nie przysporzyło żadnych problemów. Pierwszy test z głowy. Instalacja – passed. Później powtórzy to jeszcze parę razy, teraz jednak chciał przelecieć na szybko wszystkie ekrany, aby upewnić się, że basic flow działa bez problemów.  Działa. Programista vs Tester 1:0. Aplikacja wyglądała na dobrze zrobioną.

Teraz mógł na poważnie wziąć się do pracy. Najpierw wykonał scenariusze z wcześniej przygotowanego test planu. Znalazł kilka minorów i dwa majory – nic specjalnego. Wszystko odnotował w Jirze podając kroki potrzebne do reprodukcji, wersję androida i urządzenie. Następny krok to testy eksploracyjne. Szczególnie dumny był z tego, że udało mu się przekonać do nich klienta. Po ostatniej akcji, gdy za ich pomocą znalazł kilka krytycznych błędów, klient chętnie płacił za dodatkowe godziny poświęcone na ten rodzaj testowania. Kilka minut testów i Jira wzbogaciła się o kolejne kilka bugów. Teraz tylko korzystając z zasady „bug clusteringu” dokładniej przejrzy jeden obszar i testy Androida będzie mógł uznać za zakończone. Sześć godzin i dwie kawy później testy były skończone. Rezultaty tez były zadowalające. Aplikacja była dobrze zrobiona, a możliwość bawienia się drogim sprzętem była dodatkowym atutem. Testy w pionie, poziomie, gesty – wszystko sprawdzone. Mizianie telefonu można było uznać za zakończone. Dokończenie formalności zostawi sobie na jutro. Teraz pora na Appla.

Do sprzętu z nadgryzionym jabłkiem Zigi zawsze miał mieszane uczucia. Niby sprzęt był dobry i działa bez zastrzeżeń, jednak z jakiegoś powodu Zygfryd go po prostu nie lubił. Może to przez cenę, może przez to, że sprzęt był uwielbiany przez hipsterów i innych dziwolągów. Tak czy owak przetestować trzeba. Zigi włączył telefon i poczekał na załadowanie się pierwszego ekranu. Jego oczom ukazała się informacja o dostępnej aktualizacji systemu. W tym momencie zadrżał, a jego plecy oblały się zimnym potem. Z drżeniem rąk odłożył IPhone’a i podniósł Galaxy S7. Szybko sprawdził zainstalowana wersję androida. 6.0 Marshmallow. Z rosnącym napięciem otworzył dokumentację, zawierającą wymagania od klienta. Sprzęt nie był sprecyzowany, ale wersja Androida już tak: 5.0 Lollipop. Sytucja nie wyglądała na ciekawą. Jak to się stało, że zapomniał sprawdzić wersji software? Był pewnie, że jeszcze wczoraj zainstalowana była wersja 5.0. Pewnie ktoś bez jego wiedzy i informowania kogokolwiek zaktualizował telefon do najnowszej wersji. Sześć godzin testów do kosza. Trzeba wszystko zaczynać od początku. Zygfryd spojrzał na zegarek – 16: 30, pora oddawania sprzętu. Po tym czasie szafka ze sprzętem była zamykana. Trzeba będzie jutro się sprężyć i przetestować od początku Androida plus iPhona. I tak osoba, która zaktualizowała mu telefon będzie miała ostro przesrane. Tak łatwo tego nie popuści.

Zigi zerwał się z krzesła i pobiegł do szafki. Wyciągnął pierwszy z brzegu telefon z Androidem i wrócił do biurka. Oby ten miał wgraną wersję 5.0. Miał. Wkurzony na maksa wrzucił aplikację i kliknął w ikonkę. Przez chwile zobaczył pierwszy ekran powitalny, po czym aplikacja się wysypała i jego oczom znów ukazał się ekran główny. Pięć prób później efekt był taki sam. Crash aplikacji przy start-upie.

Jutro zapowiada się ciekawy dzień. Pełen nadgodzin. Darmowych nadgodzin…

 

Seminaria i szkolenia

Wśród pracowników biurowych tzw. „korposzczurów” bardzo pożądanym elementem pracy są szkolenia. Zwłaszcza te teoretyczne. Najlepiej o soft skillach. Wystarczy przyjść, posłuchać, dostać certyfikat i wyjść. To wszystko w godzinach pracy za stawkę 100%. Człowiek nic nie musi robić, a pieniążki lecą. Czy wiedz się przyda? Czy można ją będzie wykorzystać w praktyce? Nie jest to ważne. Ważne jest, że firma płaci, a korpuszczur zrobi wszystko, żeby zarobić, a się nie narobić.

Co innego jest ze szkoleniami praktycznymi, lub takimi, za które chociaż częściowo trzeba zapłacić. Tutaj pracownik dobrze się zastanowi, czy jest sens inwestować swoje pieniądze. A co jeśli po szkoleniu jest egzamin? Trzeba będzie się uczyć samemu w domu! Może jednak warto się rozwijać i poznać coś nowego, nawet jeśli na razie zdobyte umiejętności nie zostaną użyte w praktyce? Chociaż z drugiej strony…W końcu mamy efekty bazując na tym, co już znamy i nie ma sensu robić inaczej. Co ten trener/coach/nauczyciel może wiedzieć? Mój projekt jest specyficzny i nic z tym nie da się zrobić.

W BJJ od czasu do czasu organizowane są seminaria. Przyjeżdża znany, doświadczony czarny pas, który przez 4h pokazuje nowe techniki. Po krótkim pokazie można je przećwiczyć. Niestety seminarium nie wolno nagrywać, nie dostaje się też żadnych materiałów. Co zapamiętasz – to Twoje.

Ile ze zdobytej wiedzy wykorzystasz w praktyce? Poznałeś nowego sweepa z półgady? Przecież masz już swojego konika w tym temacie! Po co Ci coś nowego? Kolejne zajście za plecy? No prośba! Ile ja będę musiał to ćwiczyć? Znowu 1000 powtórzeń na każdą stronę, żeby w ogóle móc użyć to w walce?

A może jednak wykorzystam to, czego się nauczyłem? W końcu seminarium nie prowadzi byle kto. Przeważnie jest to mistrz świata z większa ilością tytułów niż ilość znalezionych przez Ciebie błędów. To znaczy, że to, co pokazuje, działa. Dodatkowo seminaria są płatne przez uczestników. Żaden klub nie dokłada się do nich. 100% płacy spoczywa na uczestniku, co oznacza, że seminarium wybiera się bardzo starannie, tak, żeby móc z niego jak najwięcej skorzystać. Tracisz swój czas, czasami musisz brać specjalnie urlop, więc jak już idziesz to po to by się czegoś nauczyć, a nie żeby się pokazać i móc chwalić, że byłeś na seminarium. Prawda?

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