Ważne i ważniejsze

Robimy dla klienta aplikację. Zarówno Android jak i iOS. Problemem jest to, że designy dostarcza nam zewnętrzna forma od strony klienta. W ten oto sposób mamy designy, mocki, wersje na iOS i wersję na Androida…. każdą inną.

A bo tutaj kolor jest trochę inny. na iOS jest przycisk przesuniety, a bo kalendarz trzeba było zrobić natywnie i już nic się nie zgadza. Problemów bez liku, ale nie poddajemy się. Zgłaszamy błędy skupiając się głównie na funkcjonalności, ewentualnie zgłaszamy grube błędy w designach.

Przychodzi czas na pierwsze demo, potem drugie demo i okazuje się, że klienta ma gdzieś, że aplikacja działa. Dla niego ważne jest żeby wyglądała, „ładnie”. Tam literka, tu kropeczka, przecineczek i kolorek mają teraz bugi z ważnością critical. A to, że coś tam się nie działa? kogo to obchodzi. W końcu klienta nasz PAN 🙂

Selenium NIE dla początkujących

Zigi pełen niepokoju usiadł przed komputerem. Pełen zgrozy i umiarkowanego optymizmu chwycił za mysz i kliknął w ikonkę Eclipsa na swoim Windowsem. Po chwili jego oczom ukazał się ekran główny jego świeżo zainstalowanego środowiska programistycznego. Dwa kliknięcia później na ekranie już widoczna była pusta, biała strona, a u samej góry wesoło migał kursor, zachęcając do napisania pierwszej linijki kodu. Ten dzień w końcu nadszedł. Zygfryd zaczął uczyć się automatyzacji testów.

Ten dzień był nieunikniony, jednak Zigi odwlekał go jak tylko mógł. Przecież był testerem – nie programistą. Dlaczego więc ma się uczyć jakiegoś języka programowania? Jakby chciał zostać developerem, to wybrałby inne studia i inaczej pokierował swoja karierą. Tymczasem w firmie, gdzie pracował, przesłanie było proste: Nie automatyzujesz – nie pracujesz.

Niepocieszony, że musi wyjść ze swojej strefy komfortu, Zygfryd wpisał w Google: Selenium dla początkujących i zaczął czytać. Godzinkę później był już w stanie napisać parę pierwszych linijek kodu. Sam koncept nie wyglądał na skomplikowany. Otwórz stronę, znajdź element i wykonaj na nim jakąś akcję. Raptem pare komend, nic trudnego. Driver, get URL, Select by ID, click i enter!! Jego pierwszy program zaczął się kompilować. Po chwili na ekranie otworzyła się przeglądarka Chrome, a w pasku zaczął wpisywać się adres strony głównej Google. Chwila prawdy zbliżała się nieubłaganie. Zygfryd zacisnął kciuki i z skoncentrował wzrok na polu wyszukiwarki. Sekundę później ukazał się w niej tekst: „asdfasdfadsf”, a dwie sekundy później został wciśnięty przycisk szukaj. Widząc sukces swojego pierwszego projektu Zigi aż podskoczył z radości. Chyba zbyt pochopnie ocenił i przestraszył się automatyzacji. Teraz wystarczyło nauczyć się dostawać do elementów po xPath, CSS, klasie itp. i właściwie tyle. Wszystko inne wydawało się proste.

Zadowolony z pierwszych sukcesów, nasz tester automatyczny, jak w myślach zaczął na siebie mówić, przerzucił się w Google na swój docelowy projekt. Na szczęście element, do którego chciał się dostać miał nadany ID. 10 minut później był gotowy do odpalenia kolejnego programu. 11 minut później zdruzgotany niepowodzeniem Zigi przeklinał automaty i wszystkich programistów. Jego program nie zadziałał. Diagnoza według jego kumpla: AJAXy się nie załadowały, trzeba nadpisać metodę wait, tak żeby czekała na załadowanie wszystkich elementów na stronie. Poza tym, należy stworzyć osobne klasy na lokatory, executory, zapoznać się z Page Object Pattern i PageFactory i zrobić całkowity refactoring kodu.

Smutny i pełen nienawiści do programowania i samego siebie Zigi zamknął IDE i w Google ponownie wpisał: Selenium dla początkujących. Zapowiadał się długi dzień.

Dobra zmiana

Nic tak nie pobudza mózgu do pracy, jak robienie czegoś nowego. W momencie, gdy wydaje nam się, że przestaliśmy się rozwijać, a testowanie czy BJJ przestały sprawiać przyjemność to znak, że najwyższy czas na zmianę. Nie drastyczną, nie na stałe, tylko po to, żeby pobudzić mózg do działania i za jakiś czas wrócić do pierwotnych zajęć z pełną werwą.

BJJ nie jest jedyną słuszną sztuką walki. Boks tajski, MMA, Kickboxing, a może siłownia? Każda z tych aktywności będzie miłą odmianą od treningu parterowego. Inne mięśnie zostaną zaprzęgnięte do pracy, inaczej trzeba będzie balansować ciałem. Zdobędziemy nowe umiejętności, poprawimy koordynację i przekonamy się, czy forma zdobyta ma macie ma przełożenie na inne sporty.

Co powinien zrobić tester w chwilach stagnacji? Zacząć programować? Blogować? Kręcić filmy na YT. Tutaj odpowiedź nie jest prosta. Ciężko jest zacząć programować tak, żeby już od samego początku mieć z tego radość. Blogowanie to też nie jest zajęcie na 2 tygodnie. Może zacząć się uczyć nowego języka obcego? Rozpocząć naukę gry na instrumencie? Każda aktywność jest dobra, byle tylko oderwać się od rutyny testowania.

No dobrze, a co z aktywnościami biernymi? Może lepiej odpuścić sobie sporty i zacząć oglądać seriale? Tyle fajnych filmów jest do obejrzenia i książek do przeczytania. Już nie wspomnę ile rodzajów piwa jest do spróbowania! Wszystko jest dla ludzi, jeśli używa się tego z rozsądkiem. Możesz wypić dwa piwa, iść na trening, potem pouczyć się chińskiego i na końcu obejrzeć serial w HBO. Jeśli tylko to pobudzi Cię do działania, to droga jest otwarta. Ty znasz siebie, wiesz jak reagujesz na dany bodziec. Cokolwiek robisz, rób to z głową. Ja wybrałem boks tajski i język hiszpański.

 

To mała poprawka, nie ma sensu tego dokładnie sprawdzać.

„To tylko mała poprawka.” „Drobny improvement, nic wielkiego, szkoda czasu na testy” Ile to razy słyszymy to z ust programistów? Prawda jest taka, że testerzy muszą być czujni na każdym kroku i pamiętać, że jak coś jest źle przetestowania, to pewnie nie zadziała.

Klient zażyczył sobie małe ulepszenie wyszukiwarki: Obok pola szukaj, damy pole hotel i samochód, które będą przerzucać do nowych stron, gdzie będzie sobie można wyszukać hotel, lub wypożyczyć samochód. Estymacja ze strony developerów: 6h. Czyli projekt bardzo malutki.

Testy zrobione po macoszemu i na szybko – w 30 minut. Klik – przenosi na stronę hotelu. Powrót na stronę główną, klik na drugą zakładkę – przenosi do wypożyczali aut. Jeszcze z przyzwoitości wciskamy F12, żeby sprawdzić wersję represywną – działa. Przynajmniej dla Iphona 6.Powtarzamy to samo dla każdego obsługiwanego języka i po 30 minutach projekt może iść na testy akceptacyjne do klienta.

Godzinę później pierwszy email: Strona hotelu i wypożyczalni są również w kliku językach, więc w zależności od wyboru języka, powinna nowa strona otwierać się w danym języku, a nie tylko po angielsku. Patrzymy do wymagań: Po kliknięciu ma przenosić na stronę cars.com i hotels.com. Brak jakiejkolwiek wzmianki o wersjach językowych.

Pół godziny później kolejny mail: Po wyłączeniu zakładek rozjeżdża się rysunek pod spodem. Sprawdzamy lokalnie: u nas działa. Prosimy więc o screena: faktycznie – rozjechany. Jaka jest różnica? U klienta nie ma panelu do zmiany waluty, ponieważ ma IP z kraju, gdzie jest Euro. U nas okienko z walutą domyślnie jest. Wyłączamy – faktycznie obrazek rozjechany. Na szczęście problem jest po stronie grafika klienta.

W końcu dostajemy nową grafikę. Szybki fix developerów i można wysyłać. Tym razem jednak siadamy do testów raz jeszcze, w większą ilość osób. Sprawdzamy wersje językowe, linki, responsywność itp.  Okazuje się, że na Iphonie 5 dla języka greckiego słowo „Auto” nie mieści się  w ramce…a miał być mały, szybki projekt. Bijemy się w piersi. Podeszliśmy do tematu po macoszemu i  na odwal się –  NIGDY WIĘCEJ!

Tłumaczenia – uroki pracy testera

Zygfryd z nietęgą miną spoglądał na tłumaczenia dostarczona przez klienta. Sześć języków: angielski, niemiecki, hiszpański, francuski, włoski i grecki, z czego Zigi rozumiał tylko angielski. Myśl, że już jutro developerzy podmienią tłumaczenia na docelowe i wrzuca cały projekt do testów przerażała go bardziej niż kolumna samochodów BOR jeżdżąca na sygnale przez miasto. Pięć stron A4 tłumaczeń, w tym język grecki, który wygląda jak pismo, jakim posługują się Obcy z zaświatów. I jak tutaj dobrze i sumiennie sprawdzić, czy wszystkie tłumaczenia wrzucone przez devsów, zgadzają się z tymi, które dostarczył klient?

Na drugi dzień Zigi z jeszcze bardziej podłym humorem usiadł przy biurku i odpalił PC. Wiadomość na Slacku, że tłumaczenia są już gotowe do sprawdzenia, nie była dla niego żadnym zaskoczeniem. Z niesmakiem odpalił pierwszą stronę aplikacji, na drugim ekranie otworzył excela z tłumaczeniami i słowo po słowie zaczął porównywać teksty. Na pierwszy ogień poszedł hiszpański.  Po godzinie sprawdzania miał już serdecznie dość. „Zostań testerem mówili, będzie fajnie mówili” – narzekał sam do siebie w myślach. „A trzeba było iść na operatora koparki. Wszyscy się z tego pomysłu śmiali, ale kasa, jaką oferowali dla operatorów, z pewnością nie jednego przekonałaby do zmiany zawodu” – kontynuował rodzinną tradycję marudzenia.

Z ciekawości Zigi otworzył jeszcze tłumaczenia dla języka niemieckiego i francuskiego. Pierwsze, co rzuciło się mu w oczy to fakt, że część tekstów jest pogrubiona. Z niepokojem otworzył wszystkie tłumaczenia i sprawdził pobieżnie całość.  Okazało się, że dla różnych języków, różne teksty w różnych miejscach są pogrubione. Czy tak wynika z kultury danego języka? Czy to jest błąd? Czy developerzy powinni do aplikacji również wrzucić pogrubione teksty? Ilość potencjalnych problemów rosła w zastraszającym tempie.  Nawet heroiczna próba skopiowania testów z aplikacji do Notepada++ i użycie wtyczki Compare okazała się nieskuteczna.  Co robić, jak żyć?

W tym momencie Zigi zauważył, że na skrzynkę mailową przyszła nowa wiadomość email. Kątem oka Zygfryd zauważył tylko jedno słowo – praktykanci. W tym momencie Zygfryd poczuł, jak nowa, co by nie mówić wręcz wspaniała, myśl, przychodzi mu do głowy. W końcu każdą osobę da się zastąpić skończoną ilością praktykantów. Tak strasznie wszyscy chcą zostać testerami. Przecież to takie, łatwe, proste i przyjemne. Parę kliknięć myszką i po pracy. No to teraz zobaczymy jaką będą mieć minę, jak zobaczą 30 stron tłumaczeń do sprawdzenia.

Zadowolony z siebie, jak nigdy wcześniej, Zigi kliknął na maila prawym przyciskiem myszy i z listy wybrał słówko -Odpowiedz. W nowym oknie przeszedł do pola z wiadomością i zaczął pisać: Hej, będę miał robotę dla praktykantów…

Klient – władca wymagań

Niezwykle modnym (wręcz obecnie jedynym słusznym!) podejściem do wytwarzania oprogramowania jest podejście zwinne. Kod, testy oraz wymagania cały czas dynamicznie się zmieniają. Daleko nie szukając: Mail od klienta precyzujący wymagania, wysłany o 11:37:

„…process must assign passengers…”

W zespole panika, ponieważ przetestowany I oprogramowane było zachowanie zupełnie odwrotne. Pożar na całego, gdy nagle o 11:49 przychodzi kolejny mail od klienta:

„ Let me correct the last sentence. … process should not assign passengers…”

I jak tu nie lubić tej pracy…

Kto jest odpowiedzialny za jakość oprogramowania?

Kto stoi na straży jakości oprogramowania? Wiadomo – tester. Do czego sprowadza się więc jego rola? Wytykania gdzie developer popełnił błąd? Marudzenia, że znowu nie ma dokumentacji technicznej? Zdawania trudnych pytań klientowi? Co tak naprawdę sprawia, że możemy nazywać siebie strażnikami jakości?

Czy projekt informatyczny mógłby się udać bez udziału testera? Teoretycznie tak. Co do jego jakości możnaby się wspierać, ale nie ma przeciwskazań, żeby wypuścić software nieprzetestowany.

Natomiast czy można stworzyć software bez udziału programistów? Nie. Więc to programiści, jako niezbędny element projektu informatycznego powinni być odpowiedzialni za jakość. Powinni, ale nie są. Co innego jest napisać kod, a co innego napisać działający kod zgodnie z życzeniem klienta, spełanijący dane reguły biznesowe itp. Dlatego też niezbędna jest tu rola testera.

   Programista jest osobą konieczną, ale niewystarczającą aby projekt informatyczny miał szansę powodzenia.

Najlepiej, gdy programista i tester uzupełniają się nawzajem. Wygląda na to, że testerzy i programiści uzupełniają się nawzajem. Jeden ma wiedzę domenową, drugi ma pogląd na całość projektu. Programista wie CO ma działać, tester wie JAK to coś ma działać. Ostatecznie oboje są odpowiedzialni za jakość dostarczanego produktu. Od ich podejścia zależy, jaka będzie ostateczna ocena ich pracy.

Jeśli po zgłoszeniu błędów programista zaklnie i zwyzywa, że te łajzy znowu się czepiają, a przecież tłumaczył im, że to tak ma działać to zacząłbym się martwić o powodzenie projektu. Z drugiej strony tester wyzywający, że znowu w tym samym miejscu, ta sama funkcjonalność nie działa, też nic dobrego nie osiągnie.

Kluczem do sukcesu jest komunikacja, wzajemne zrozumienie i wyjście na piwo raz na jakiś czas. Nic tak nie rozwiązuje problemów jak kufel dobrej craftowej IPY.

Jak testować coś nowego?

Nikt nie wie wszystkiego. Nie ma osoby, która na poziomie zaawansowanym umie przetestować wszystko. Webówka, aplikacje mobilne, aplikacje desktopowe, backend, frontend, testy sprzętu – tego jest po prostu za dużo. Co więc zrobić, kiedy jesteśmy wrzucani do projektu, gdzie musimy zająć się rzeczami o których nie mamy pojęcia?

W BJJ, zanim zastosuje się nową, nieznaną wcześniej technikę w walce powtarza ją się w nieskończoność na treningu. Zaczyna się og oglądania, jak wykonuje ją trener. Następnie ćwiczy się ją z partnerem, starając się „złapać ruch”. Następnie coraz płynnie, przy zachowaniu koordynacji i detali. Kolejny krok to walki zadaniowe, gdzie przeciwnik stawia czynny opór ale nie na 100%. Powyższe działania trzeba powtórzyć 100 razy, po czym można uznać, że dana technika nie jest nam obca. Oczywiście wykonywać dźwignię/duszenie/sweepa na treningu a wykonywać w walce to dwie zupełnie różne rzeczy. Jak w większości przypadków potrzeba czasu, cierpliwości i systematyczności.

No dobra, a co z testowaniem oprogramowania? Mam iść do seniora i powiedzieć: Ej, stary! Jak się testuje mobilki, pokarzesz mi parę sztuczek? – Słabe, co nie?. Człowiek najwięcej się uczy robiąc rzeczy samodzielnie. Osobiście zacząłbym od google.com oraz youtube.com. Z pewnością problem, który dla nas jest oryginalny, nie raz i nie dwa był przerabiany już w Internecie. Na początek, trochę teorii. Co będziemy testować? Czy ekspert z dziedziny QA wygłosił może konferencję na interesujący nas temat? Czy są jakieś filmiki szkoleniowe, na których ktoś pokazuje, jak należy testować. Jakich narzędzi pomocniczych będę potrzebował? Postmana, Jmetera?

Teorię mamy już za sobą. Pora przejść do praktyki. Na całe szczęście, istnieją środowiska testowe. Tam możemy zacząć przygodę z czymś nowym od najprostszych rzeczy. Testujesz API? Wyślij najpierw jedno, najprostsze zapytanie GET i zobacz, co i w jakiej formie dostaniesz w odpowiedzi. Aplikacja mobilna? Włącz, obróć ekran, przeskroluj, zapytaj się analityka, co ona ma robić. Testujesz sprzęt? Podłącz go do prądu (tak, zdarzyło się znajdywać błędy, związane z tym, że sprzęt elektroniczny lepiej działa, jak się go podłączy do źródła zasilania).

Zasada mówi: od ogółu do szczegółu. Stopniowo wchodź coraz głębiej w funkcjonalności, poznawaj nowe rzeczy i nie bój się zadawać pytania. Jeśli myślisz, że programista ma już Cię dość, to z pewnością nie znasz tych, z którymi ja pracujęJ Wiem, że mają mnie serdecznie dość, ale gdy czegoś nie wiem, to się pytam, a nie domyślam. W końcu razem odpowiadamy za jakość produktu, który dostarczamy.

Z pewnością, im mamy więcej doświadczenia, tym łatwiej będzie nam z nowymi rzeczami. W BJJ mamy pamięć ruchową, czyli pewne czynności robi się automatycznie i nie trzeba się na nich skupiać. W testowaniu oprogramowania wiele rzeczy jest wspólnych, niezależnie od tego co testujesz.  Każda nowa rzecz, to wyzwanie, z której płyną same benefity. Pytanie, jak szybko będziemy spijać śmietankę z efektów naszej pracy?

Eksploracja bez dokumentacji

Zygfryd ze zdumieniem czytał najnowszego maila. Wprost nie mógł uwierzyć temu, co właśnie czytał. Czuł się jakby właśnie dostał prezent urodzinowy i to lepszy niż PS4, które dostał od żony w tym roku. Z niedowierzaniem jeszcze raz przeleciał wzrokiem tekst od góry do dołu. Klient zgodził się, aby testy w projekcie zostały przeprowadzone za pomocą testów eksploracyjnych. Bez test planów, bez test casów, bzdurnych opisów i dokumentacji. Ba! Mało tego, klient zrezygnował z testów automatycznych na rzecz eksploracji!

Do tej pory Zigi nie wiedział, że ma aż taki dar przekonywania. W ciągu godzinnej rozmowy z klientem namówił go na wszystko co chciał. Teraz czuł się, jakby właśnie samego Pana Boga złapał za nogi. Cały czas spędzony w projekcie będzie mógł przeznaczyć w końcu na testowanie a nie pisanie bzdurnych i nikomu nie potrzebnych test planów i obszernej dokumentacji. Jednak marzenia się spełniają.

Kilka dni później pierwsza wersja aplikacji była gotowa na testy. Zygfryd wygodnie rozsiadł się w fotelu, przymknął oczy i zaczął intensywnie myśleć jakie testy by tu wykonać. Po chwili już wiedział. Po prostu odpali aplikacje i przeklika wszystko co mu przyjdzie do głowy. W końcu przy jego doświadczeniu plan działania nie jest potrzebny. Zadowolony z siebie odpalił aplikacje i przystąpił do testów.

Niecałe 6 godzin później pierwsze testy zostały zakończone. Zigi był zadowolony z siebie jak nigdy. Znalazł kilka błędów krytycznych, parę minorów i kilkanaście literówek. W sumie dzień można uznać za udany. Kątem oka zerknął jeszcze na skrzynkę mailową. U samej góry była jedna nieprzeczytana wiadomość. Była od Steve z teamu z USA, który razem z naszym niezłomnym testerem sprawdzał aplikację. Dziękował on mu za dzisiejszą pracę, gratulował znalezionych błędów i prosił o podsumowania, co dzisiaj zostało przetestowane, aby mógł kontynuować testy. W tym momencie Zygfryd oblał się zimnym potem. No właśnie, co on dzisiaj tak naprawdę przetestował? Znalazł błędy, to fakt, ale jakie obszary pokrył testami? W sumie to na pierwszej stronie sprawdził walidacje pól, na drugiej obsługę błędów. Potem sprawdził wynik działań algorytmów i coś tam zerknął do API. Na stronie z podsumowaniem w sumie nie pamiętał co sprawdzał, ponieważ gdy ją testował do pokoju weszła szefowa HRu i przedstawiła nową koleżankę, która dzisiaj zaczynała pracę. W tym momencie krew odpłynęła Zigiemu z mózgu w zupełnie inne miejsce. Spocony, Zigi na szybko napisał bardzo ogólnikowego maila, wyłączył telefon, żeby Steve nie mógł się z nim skontaktować i czym prędzej poszedł do domu.

Następnego dnia, Zigi z niepokojem czytał maila do swojego kolegi z zza ocenau. Steve pisał, że sprawdził główną funkcjonalność aplikacji, następnie obsługę błędów na wszystkich stronach oraz zostawił włączoną aplikację, tak aby sprawdzić, czy dalej będzie działać po 24h nieprzerwanej pracy. Dodatkowo wysłał skan swoich notatek, gdzie spisał swoje spostrzeżenie, obszary warte ponownego sprawdzenia i wnioski. Poziom zdenerwowania Zygfryda rósł z każdym kolejnym czytanym zdaniem. Jego kolega ze Stanów był w tym momencie od niego lepszy. Przeprowadził lepsze testy i dał dużo lepszy feedback na temat swojej pracy. Zdenerwowany, ale z drugiej strony nieco zrezygnowany Zigi odpalił Google i wpisał nową frazę do wyszukiwarki: how to test using exploratory tests books…