Trudne decyzje, niełatwe rozwiązania.

Opublikowany przez

Zigi jak co wieczór siedział przed komputerem. Jednak tym razem na ekranie nie było widać żadnej strony internetowej, ani żadnej gry. Spotify też był wyłączony, co znaczyło, że Zygfryd potrzebuje całkowitego skupienia, a jego chwilowa inteligencja przewyższała nawet możliwości Kuby Wędrowycza.

Zamierzał zrobić to już od dłuższego czasu, jednak jakaś wewnętrzna siła, cały czas powstrzymywała go od decyzji. Wiedział, że jest na to gotowy. Miał doświadczenie, chwytliwy temat i gotową prezentacje. Dlaczego więc wciąż się wahał? Jeszcze raz spojrzał na daty. Deadline wypadał 18 czerwca. Jeszcze był czas, jednak co będzie jak jego zgłoszenie zostanie odrzucone? Co jeśli jego prezentacja zostanie słabo oceniona? W chwilach takich jak ta, Zigi odwoływał się do wyższych wartości. W momentach zwątpienia zadawał sobie jedno pytanie: Co by zrobiłby Geralt z Rivii?

Odpowiedź była prosta! Nie zważając na przeciwności, nie oglądając się na innych prezenterów Geralt by to zrobił. Wysłałby swoje zgłoszenie w odpowiedzi na Call for Papers na konferencę TestWarez 2018. Zygfryd powoli chwycił myszkę, najechał na ikonę przeglądarki i dwukrotnym kliknięciem otworzył Internet Explorer. Chwila refleksji przyszła szybciej, niż zdążyło się otworzyć okno przeglądarki. Zigi szybko zamknął IE i otworzył Chroma. Jak adres URL podał www.testwarez.pl.

Był zdecydowany. Wiedział, że teraz jest jego chwila. W jego głowie nie tylko Geralt, ale i inni bohaterowie podpowiadali mu, że teraz jest jego chwila.  Wypełnienie formularza zajęło mu niecałe 5 minut. Oto on: tester, mąż, gracz, prezenter na konferencji TestWarez 2018.

Trudna sztuka udzielania feedbacku

Opublikowany przez

Zigi od rana był w dobrym humorze. Jego testy automatyczne chodziły bez zastrzeżeń, jego forma na treningu rosła z dnia na dzień, a cena piwa kraftowego systematycznie malała. Jednym słowem powodów do narzekań Zygfryd – nie miał.

Z dużą dawką optymizmu powitał więc nowego maila, który przyszedł na jego skrzynkę. Była to wiadomość od jednego z liderów zespołów testowych. Z treści wynikało, że zbierał on informacje o jednym z jego kolegów z zespołu, w celu dokonania uczciwej oceny roczne. Prosił więc on Zigiego o feedback, aby móc, bądź co bądź w sposób uczciwy, ocenić kolegę Zigiego – Tomka.

Zygfryd akurat miał zrobić sobie zasłużoną przerwę, jednak zdecydował się popracować jeszcze 5 minut i szybko odpisać liderowi. Rozsiadł się wygodnie w fotelu i wytężył mózgownicę.

Co można było powiedzieć o Tomku? Robił swoje, przykładał się do pracy, większych wpadek nie zanotowano. Polecam tego allegrowicza? Bez sensu. Przecież to samo można by powiedzieć o każdym! Zygfryd zastanowił się jeszcze chwilkę, chcąc wyciągnąć ze swojego zrelaksowanego mózgu jakiekolwiek konstruktywne informacje o Tomku. Nic…pustka…Dobry humor zaczął być zastępowany przez zirytowanie i gniew. Wizja przerwy oddalała się z minuty na minutę a do wachlarza emocji doszło wkurzenia, poddenerwowanie i lekki wkurw. 30 minut później w treści maila jedyne co istniało to adres nadawcy i stopka z danymi Zigiego, która dodawała się do każdej wiadomości automatycznie.

Rezygnacja była czynnością, który Zygfryd nie wykonywał zbyt często. Jego ambicja nie pozwalał na zbyt szybkie rezygnowanie z zaczętych rzeczy. Nie inaczej było tym razem. Bliski rozpaczy Zigi odpalił Google i w polu wyszukiwarki wpisał: Jak udzielać konstruktywnego feedbacku. Na ekranie zobaczył linki prowadzących do najwybitniejszych coachów polskich. Coaching. Na samą myśl o słuchaniu tych bzdur zrobiło mu się niedobrze. Gadanie o strefach komfortu, wyjścia z cienia, pracy nad uczuciami powodowała u niego odruchy wymiotne. Jednak tym razem nie miał innego wyjścia. Z drżeniem serca odpalił pierwszy znaleziony filmik. Gęba, jaką zobaczył, już sama w sobie była wyrocznią, jakiego rodzaju feedback na temat obejrzanego materiału zostawi w komentarzach.

Ważne i ważniejsze

Opublikowany przez

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

Opublikowany przez

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

Opublikowany przez

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

Opublikowany przez

„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

Opublikowany przez

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ń

Opublikowany przez

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?

Opublikowany przez

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?

Opublikowany przez

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?