Cztery metody powrotu do formy.

Kontuzje, wypadki losowe, L4. Lista rzeczy, która może uniemożliwić pracę i treningi jest długa. Przerwa od trenowania ciała i umysłu może trwać nawet miesiącami. Jak wrócić do pełnej formy po dłuższej przerwie?

Znasz to uczucie, kiedy przychodzisz na matę i jedynym pomysłem jaki masz podczas walki to balacha z gardy? Berimbolo? To chyba była nazwa drinka. Rolling panda na rozgrzewce? To jakiś taniec nowoczesny?

Wracasz do pracy, a jakiś junior pyta się ciebie o 7 zasada testowania. Coś tam było w sylabusie ISTQB, który zdawałeś 10 lat temu. Przypominasz sobie trzy a potem symulujesz kaszel, aby jak najszybciej móc się oddalić. Co więc robić? Jak żyć?

  1. Rozciągaj się

Wielu zawodników traktuje rozciąganie jak homeopatię. To po prostu wymysł jakiś znachorów i nie ma prawa działać. Traci się tylko cenny cza, podczas którego możnaby zrobić masę. Nic bardziej mylnego. Rozciąganie jest bardzo skuteczne i pozwala utrzymać ciało w dobrej kondycji, nawet wtedy gdy nie możemy normalnie trenować. W zdrowym ciele zdrowy duch. Łatwiej jest wrócić do pracy i na matę, gdy mimo wszystko człowiek się trochę porusza.

  1. Trening mózgu

Mózg też można, a właściwie trzeba trenować. Czy to oglądanie walka na YT (walk BJJ, nie kotów, wypadków, seriali, tylko walk najlepszych zawodników na świecie), czy rozwiązywanie sudoku, taki trening pozwoli w łatwiejszy sposób wrócić nam szybciej do pełnej formy. Oglądanie prelekcji z konferencji testerskich? Czemu nie. Jak nie teraz to kiedy?

  1. Back to basics

Powrót do podstaw. Nie ma lepszego pomysłu na spędzenie czasu jak powtórka absolutnych podstaw. Książka Adama Romana „Testowanie i jakość oprogramowania” może nie jest najlepszą lekturą do poduszki, ale skrypt ISTQB już tak. Przypomnienie sobie podstawowych sweepów i technik kończących jest jak najbardziej wskazane.

  1. Nakręcanie się na powrót

Ostatnie metoda. Wizualizacja tego, co się będzie działo po powrocie. O czym będziesz gadał z kumplami na treningu? Że znowu przytyłeś, pfu! Zrobiłeś masę? Że symulowałeś? Że znowu Cię żona z domu puścić nie chciała? A w pracy? Że projekt żyje i ma się dobrze, klient jest zadowolony, a Twoja obecność w cale nie jest niezbędna, tak jak się to PMowi wydawało. Że znowu bug na produkcji wyszedł o 2 w nocy, lub co gorsza, automat do kawy się zepsuł.

Czy stosowanie się do powyższych zasad pomoże? Z pewnością! Jestem tego przykładem. Najgorsze to nic nie robić. Wiem, że dobry serial nie jest zły, ale warto poświęcić trochę czasu na inne rzeczy. Wysyłek niewielki, a benefity ogromne. Osssss!

Projekt ławka

Jak to w każdej większej firmie zdarza się, że testerzy „siedzą na ławce”. Innymi słowy: projektu nie ma i póki co nie będzie. Co wówczas robić, gdy musimy siedzieć 8h w pracy bez konkretnych zadań? Możliwości jest klika:

Self learning:

Czyli to, co właściwie powinniśmy robić. Testowanie jest olbrzymim obszarem więc każdy powinien znaleźć tutaj coś dla siebie. Frontend, Backend, aplikacje mobilne, wydajność, bezpieczeństwo itp. Tematów można by mnożyć. Minusy? Ileż można!? Dzień, dwa, tydzień nauki bez przerwy? Każdy by oszalał. Ponadto czas upływa powoli…bardzo powoli. Gdy praca do wykonania jest konkretna, wówczas czas zdaje się płynąć szybciej.

Granie w gry:

Opcja niebezpieczna, lecz kusząca. Szefowie raczej nie będą patrzeć przechylnym okiem, ale z drugiej strony, gdy w biurze jest 100 osób, to wówczas nie tak łatwo wyizolować tę, która nic nie robi. Ponadto gry rozwijają. Artykułów na ten temat też jest dość sporo. Zresztą, nie trzeba grać w gry na konsoli, zawsze są planszówki.

Work from home:

Ma sens. Skoro I tak się uczę, to czemu nie uczyć się z domu, gdzie rozpraszaczy jest dużo mniej. Warunki bardziej sprzyjają a i baza wiedzy bywa większa. Pytanie, czy ten czas pracy z domu na pewno poświęcimy rzeczywistej nauce.

Retrospektywa i porządki:

Skończyliśmy projekt, nie mamy nowego, ale może jednak warto podsumować nasze dotychczasowe dokonania. Zawsze znajdzie się obszar, w którym coś nam nie poszło, gdzie moglibyśmy cos poprawić. Warto więc zrobić porządek zarówno w dokumentacji jak i na biurku.

Oglądać YouTube:

Ilość filmów z kotami wystarczy nam na długie miesiące siedzenia na ławce. Może i nic się nie nauczymy, za to będziemy szczęśliwi. Zresztą, nie tylko koty są w internetach.

Załatwiać rzeczy prywatne:

Trzeba zrobić przelew, opłacić rachunki, zamówić prezenty, pojechać przypilnować malarza itp. Brzmi znajomo? To codzienność tych, którzy nie mają projektu. Niech kwestią naszego sumienia pozostanie jak bardzo będziemy chcieli wykorzystywać firmę do własnych potrzeb.

Zmienić pracę:

Nic tak nie demotywuje jak monotonia. Gdy czas spędzony na ławce jest zbyt długi, czasem warto po prostu poszukać innej pracy. Krok drastyczny, ale czasami konieczny.

Różowy projekt

Zygfryd z niedowierzaniem patrzył na ekran. Ilość odcieni koloru różowego raniła zarówno jego oczy jak i dumę. Dlaczego ja? Dlaczego takie rzeczy zawsze muszą mnie spotykać? –  Niestety pytanie pozostało bez odpowiedzi. Jeszcze tydzień temu myślał, że znalazł niebo na ziemi. Dostał projekt, w którym trzeba było zrobić i przetestować porównywarkę zdjęć kobiet w bikini. Projekt życia. Gołe laski na ekranach monitorów w pracy i to za pozwoleniem szefa! Lepszego projektu nie mógł sobie wyobrazić.

Niestety błogostan nie trwał długo. Raptem dwa dni po rozpoczęciu projektu, przyszedł PM i oznajmił, że jedna osoba będzie oddelegowana do innego projektu. Sklep internetowy kucyków Ponny i i innych zabawek w kolorze różowym. Tak. Klient, a właściwie klientka, wymarzyła sobie sklep, gdzie można kupić zabawki tylko w kolorze różowym. Gdy Zigi pierwszy raz zobaczył kobietę, odpowiedzialną za ‘’różowy projekt’’, omal nie spadł z krzesła. Kobieta 40-50 lat, tleniona blondi z mózgiem wielkości ameby. Pieniądze ma od mężusia, a nadmiar wolnego czasu wykorzystuje na solaria i masaże. Co spowodowało, że zachciało jej się własnego biznesu? Tego prawdopodobnie nigdy się nie dowie. A dlaczego to właśnie on musiał trafić do różowego piekła? Bo kamień bije nożyczki…

Zygfryd z niesmakiem oglądał skaczące po ekranie kucyki i jednorożce. Strony dosłownie nie dało się oglądać, jednak klienta była zachwycona dotychczasowym efektem. Abstrahująca od wyglądu, ile błędów może być w sklepie internetowym? Tyle co zawsze. Pod tym względem projekt nie odbiegał od innych. Największy problem Zigi miał z kolorami. Jako typowy mężczyzna rozróżniał trzy: fajny, brzydki i ch*jowy. Tymczasem na samej stronie głównej, według specyfikacji (jeśli można tak nazwać opowiastkę Blondi, jak strona ma wyglądać), miał trzy odcienie różowego. Zrezygnowany odłożył testy UI na bok i jeszcze raz sprawdził działanie koszyka.  Kategoria: dodatki…uprzęże dla kucyków…kolor….biały…dodaj do koszyka….cena się zgadza, ilość też. Idź dalej…kategoria jednorożce…ku*wa!…dodaj jednorożca…NIE!! Tak dalej być nie może.

Zygfryd zrezygnowany czym prędzej zamknął laptopa i wyszedł z pokoju. Poziom testosteronu znacznie spadł dużo poniżej normalnego poziomu. Musiał odreagować. Czym prędzej poszedł na drugą stronę biura, gdzie stało nowiutkie PS4 PRO. Musiał przyznać, że tym razem szef miał gest. Nowa konsolka i zestaw gier naprawdę świetnie działała jako przerywnik w pracy. Zigi rozsiadł się w fotelu i włączył konsolę. Pół godzinki gry w Street Fightera później mógł spokojnie wracać do swoich obowiązków. Nieśpiesznie i w dobrym humorze ruszył do swojego biurka.

W tym momencie jego telefon odezwał się dźwiękiem, informującym, że SMS dotarł na pokład. Zigi odblokował ekran i zaczął czytać. Dobry humor jak szybko przyszedł tak szybko odszedł. Krótka wiadomość tekstowa informowała go, że za godzinkę przyjedzie Blondi z nowym pomysłem na sklep. Tym razem będzie to muzyczka, która będzie towarzyszyć klientom będącym na stronie. Już na samą myśl o potencjalnych piosenkach, które będzie musiał przesłuchać, Zigi poczuł, że robi mu się niedobrze. Czym prędzej zawrócił i biegiem udał się z powrotem do ukochanej konsoli. Tym razem pół godzinki grania będzie zdecydowanie za mało.

Programistyczna Wieża Babel

Developerzy w danym projekcie programują w jednym języku programowania. Java, C#, .NET, nie ma znaczenia – zawsze jest to jeden konkretny język. Dzięki temu są oni ekspertami w swojej dziedzinie znając wszystkie tajniki, jak również za i przeciw danego rozwiązania.

Ile języków programowania powinien znać tester? Żadnego, bo przecież jest testerem manualnym? A jak jest automatykiem? To góra jeden. Selenium + Java. Bo teraz wszystko jest pisane w Selenium. BDD + find.by i wystarczy. Czy aby na pewno?

Czasami jest tak, że testerzy przypisani do projektu muszą sobie radzić sami z całym projektem, niezależnie od tego jakie są technologie i potrzeby, bo akurat ławka testerska jest pusta. I tak: Mamy Web aplikacje, no to piszemy Selenium+ C#, bo przecież Framework już jest i nie będziemy wymyślać koła na nowo. Web serwisy? POSTMAN/SOAPUI nie ma znaczenia, i tak będziesz pisać w Java Scripcie. Klient chce aplikacje mobilną? Developerzy zabierają się za Xamarina, więc nie masz wyboru. Musisz użyć Calabasha, a w jakim języku pisze się w Calabashu? Rubym. Do tego jeszcze na początku projektu, kiedy wydawało się, że klepania kodu w ogóle nie będzie, programik do generowania linków pisałeś w Pythonie. Potem dla klienta developerzy piszą cały backed od nowa. No to w czym piszemy testy? REST assured – czyli w Javie.  Razem daje nam to pięć różnych języków programowania. Jednak tester to cwana i pojęta bestia.

Soft skills – hit czy kit?

Czy w branży IT ważne są umiejętności miękkie? Czy dobry programista, bez umiejętności komunikacji będzie postrzegany jako gorszy i zarabiać mniej? Opinii na ten temat jest tyle, ile odpowiadających. Moim zdaniem umiejętności miękkie są równie ważne co umiejętności twarde.

Zdarzało Wam się rozmawiać z kimś na jakiś temat, po czym po 15 minutach wymiany zdań okazuje się, właściwie mówicie o dwóch różnych rzeczach? A co z kontaktami z programistami? W jednym z projektów, gdy po kolejnym wypuszczeniu softu, po raz n –ty ten sam błąd był widoczny pewien tester lubił mówić:” Kur*a ten debil znowu nie naprawił tego buga, co za osioł. Mówiłem mu że to i to nie działa, co za zjeb!” – po czym pisał maila eskalacyjnego dodając do wątku PMa, i inne osoby decyzyjne. Efekt? Żaden. Powstał dodatkowy konflikt, w który zaangażowani musieli zostać liderzy i menadżerowie z obu stron. Przykład ten pokazuje wyraźny brak umiejętności miękkich. Komunikacji – brak. Brak też było jakiejkolwiek inicjatywy zrozumienia, dlaczego problem występuje. Zero empatii, pomysłu na rozwiązanie problemu.

Po drugiej stronie mogę przytoczyć sytuacje z innego projektu, gdy developer dziękował za znalezienie błędu! Był to dla mnie szok, ponieważ nigdy wcześniej się z czymś takim nie spotkałem. Z drugiej strony po zakończeniu projektu programiści udzielili kiedyś feedbacku, na temat zespołu testerskiego. Był od dość cierpki, ale bardzo merytoryczny i oparty na faktach. Można było zareagować na niego w dwojaki sposób: Stwierdzić, że nie mają racji, nie znają się na naszej pracy, kazać im się odwalić i strzelić focha, po czym dać równie ostrą informację zwrotną, niezależnie od tego, czy byłaby ona prawdziwa. Innym sposobem, który zresztą został wybrany, było przeanalizowanie tego, co zostało powiedziane. Bez emocji, oczerniania, wszystko na spokojnie. Przeanalizowaliśmy fakty, zrobiliśmy szybkie 5-why i wyciągnęliśmy wnioski. Od razu wprowadziliśmy pewne akcje w życie, dzięki czemu nasza praca stała się prostsza i lepiej widoczna. Powstała też checklista, w której umieściliśmy wskazówki, co i jak testować i na co zwracać uwagę, bazując na naszym doświadczeniu i znając „buggy zone” w projekcie. Mała pomoc dla przyszłych testerów. Efekt: wszyscy zadowoleni. W końcu jeśli mamy się rozwijać, musimy wiedzieć co robimy źle. Pochlebstwa w żaden sposób nie wpłyną na nasz rozwój i poprawienie jakości pracy. Jest to najczęstsza bolączka juniorów, którzy boją się mówić źle o kolegach z zespołu i strasznie oburzają się na negatywny feedback na temat ich pracy.

W komunikacji codziennej umiejętności miękkie są niemalże konieczne. Problem, który można by rozwiązać w 5 minut, ciągnie się godzinami na Skype, ponieważ jedna i druga strona stara się udowodnić, że ma rację. Zero próby zrozumienia, za to wzajemne przeszkadzanie i wykrzykiwanie ciągnące się w nieskończoność.

Oczywiście poza komunikacją mamy jeszcze inicjatywę, elastyczność, umiejętność pracy w grupie, kreatywność itp. Ale to pojęcia na osobny wpis.

 

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…