Pasja Testowania ebook

Wydanie pierwsze

© Copyright — Bugfree Krzysztof Jadczyk, Krzysztof Jadczyk, 2019

Korekta — Małgorzata Woźna

Wszelkie prawa zastrzeżone. Kopiowanie, rozpowszechnianie całości lub fragmentów (z wyjątkiem cytatów w artykułach lub recenzjach) — możliwe jest tylko na podstawie pisemnej zgody wydawcy.

Wprowadzenie

Od autora

Jak to się stało, że napisałem tę książkę? Przecież nie było to moim marzeniem z dzieciństwa. Najpierw pojawił się pomysł pisania artykułów, które publikuję od września 2018 roku na LinkedIn’ie, a także na Facebooku. Od czerwca 2019 moje wpisy znajdziesz na bugfreeblog.com. Tematyka jest różna, choć zdecydowanie przeważa testowanie oprogramowania, które stało się moją pasją jakieś 13 lat temu. To wtedy zacząłem stawiać pierwsze kroki w zawodzie. Po napisaniu ponad trzydziestu artykułów postanowiłem zabrać się za większy projekt. Tak narodził się pomysł napisania tej książki. Ten, kto miał okazję śledzić moje poczynania na tych portalach społecznościowych, znajdzie tu treści, które już wcześniej ujrzały światło dzienne. Część z nich jest mniej lub bardziej przeredagowana, by tworzyć spójną całość również z nowymi, wcześniej niepublikowanymi fragmentami.

Książka jest kontynuacją pewnej myśli, która towarzyszyła mi podczas tworzenia poszczególnych wpisów. Zamysł był taki, by opisać zagadnienia związane z pracą testera dla osób, które rozpoczynają przygodę z testowaniem. Książka powstała z mojej pasji testowania, by pobudzić tę pasję u innych.

Obserwując grupy tematyczne związane z testowaniem w mediach społecznościowych, widzę, że coraz więcej osób chce rozwijać się w kierunku testowania lub chociaż zobaczyć, czy się w tym odnajdą. Słyszałem mnóstwo pytań o to, jak zacząć, czego się uczyć, z jakich materiałów korzystać i zrozumiałem, że być może wciąż zbyt mało jest przydatnych treści. Dlatego teraz chciałbym oddać Ci, drogi Czytelniku, tę oto książkę. Mam nadzieję, że znajdziesz w niej wartościowe treści.

Zanim jednak przejdziesz do kolejnych rozdziałów, chciałbym, żebyś wiedział, że treści zawarte na tych stronach są efektem mojego doświadczenia i przedstawiają mój punkt widzenia. Nie znajdziesz tu uniwersalnych zasad do zastosowania w każdej sytuacji. Zresztą tak właśnie jest z samym testowaniem. W swojej przyszłej pracy jako tester możesz nie znaleźć jednej poprawnej odpowiedzi na rozwiązanie pewnego zagadnienia. Najczęściej będzie to sytuacja typu: TO ZALEŻY. Część rozdziałów jest tylko zajawką pewnych tematów do dalszego zgłębienia. Celowo nie będę ich rozwijał ze względu na to, że bez problemu znajdziesz w sieci tutoriale lub inne materiały. Nie jest to jednak znak, że dany temat nie jest wart tego, aby poświęcić mu więcej czasu. Zdecydowanie wszystko, co jest zawarte w tej książce, uważam za minimum, by myśleć o rozwoju w kierunku testera oprogramowania. Nie rzucaj się od razu na naukę automatów i języków programowania. Najpierw zbuduj fundamenty do dalszego rozwoju, którymi według mnie jest odpowiedni sposób myślenia. Uważam, że dopiero wtedy jest sens iść dalej. Pamiętaj — najpierw solidne fundamenty, a później stawianie murów wiedzy, na których kolejno będą utrzymywać się coraz większe osiągnięcia.

Wstęp

Ważne jeszcze jest to, żebyś odpowiedział sobie na jedno pytanie. Brzmi ono następująco: Dlaczego chcę zostać testerem? Musisz wiedzieć, że droga, jaką obierasz, nie jest łatwa. Samo przygotowanie, by móc pójść na pierwszą rekrutację, zajmie pewnie kilka miesięcy. I to nie koniec. To będzie dopiero początek nieustannego uczenia się w późniejszych miesiącach i latach pracy. Czy zatem warto iść w tym kierunku? Być może odpowiedź znajdziesz właśnie w tej książce.

Zastanów się też, w jaki sposób chcesz tę drogę pokonać i przygotuj konkretny plan nauki. Plan, który jak kompas będzie wskazywał kierunek wędrówki. Bez niego możesz błądzić i momentami kręcić się bez celu, tracąc cenny czas i motywację. Nie zapomnij też celebrować nawet małych sukcesów! Warto o tym pamiętać. Wiem to z własnego doświadczenia. To będzie niezwykle ważne i pomoże Ci przetrwać chwile zwątpienia, które mogą się pojawiać.

Wyznacz sobie plan i działaj. Nie ma oczywiście nic złego w pojawianiu się odstępstw od planu. To pewnie zdarzy się nie raz i może wynikać z rosnącej wiedzy. Wtedy zmodyfikuj plan i dostosuj go do zmieniających się warunków. Ważne, żeby ćwiczyć i iść w odpowiednim kierunku.

IT kusi

Coraz więcej osób spogląda w kierunku branży IT. Powody są różne. Pewnie sam masz ich co najmniej kilka. Z jednej strony słyszy się zapewne o bajecznych pensjach oraz o morzu benefitów. Z drugiej zaś pojawiają się informacje o ciekawych, innowacyjnych projektach, które realizowane są w najnowszych technologiach. To również może wydawać się niezwykle atrakcyjne. Do tego jeszcze piękne biura, a do dyspozycji piłkarzyki, konsole, VR-y… Czego chcieć więcej? Praca marzenie! Z zewnątrz może to wyglądać jak doskonała zabawa i to jeszcze za niemałe pieniądze. Któż by tak nie chciał?

Musisz jednak wiedzieć, że nie zawsze wygląda to tak kolorowo. Nie piszę tego, żeby Cię zniechęcić, a raczej po to, by zbudować pewną świadomość. Projekty innowacyjne czy w ciekawych technologiach owszem się zdarzają. O kilku piszę poniżej. Warto wiedzieć, że nie zawsze tak jest. Zdarza się też tak, że trafia się na projekty w starszych technologiach, tzw. legacy. Nie musi to wcale oznaczać, że taki projekt nie jest ciekawy. Wbrew pozorom można się tam też sporo nauczyć. Wspominam o tym, żebyś nie był rozczarowany, jeśli nie trafisz w miejsce, gdzie będą akurat użyte najnowsze frameworki i inne dostępne narzędzia. Może się też zdarzyć, że taki legacy system trudno zautomatyzować, a regresja trwa długo i jest męcząca.

Dlaczego tak się dzieje, że wcale aż tak dużo tych niesamowicie nowoczesnych technologii nie jest używanych, choć każda firma chwali się innowacyjnością? Myślę, że powodów jest kilka:

— firma nie ma specjalistów — ludzie muszą się nauczyć nowych rzeczy, to trwa jakiś czas, a co chwilę pojawia się coś nowego. To z kolei wymusza podejmowanie strategicznych decyzji dotyczących tego, w jakim kierunku iść

— klienci nie zawsze są zainteresowani, bo mają swoje technologie, które wykorzystują i przekonanie do czegoś nowego nierzadko nie jest proste, zwłaszcza jak nie ma się ekspertów, a ma się ludzi, którzy dopiero się uczą

— ograniczenia nowinek — czasami najnowsze rozwiązania mają pewne ograniczenia i nie można ich zastosować w szerszym zakresie lub wymaga to dodatkowej, uciążliwej pracy

— brak pewności co do dalszych losów nowego narzędzia — trendy zmieniają się bardzo szybko i coś, co wydawało się fajne, za chwile już jest zastępowane przez kolejną rzecz — to nie ułatwia wyboru.

Kolejną rzeczą, o której warto wiedzieć na temat minusów pracy w IT, są terminy. Terminy, które często od samego początku są mało realne. Jednocześnie są też nieprzesuwalne i trzeba ich dotrzymywać. To tworzy presję, co zwykle nie umila pracy. Czasami mogą pojawić się nadgodziny czy praca w weekendy.

Innym ważnym aspektem pracy w IT jest również potrzeba ciągłego rozwoju. Jedni będą czuć się w tym jak ryba w wodzie, inni mogą poczuć, że zostają z tyłu. Fajnie, jeśli pracodawca wspiera ten rozwój. Zwykle tak jest. Dostaje się dodatkowy czas, ale nie zawsze jest to możliwe. Możesz też chcieć się rozwijać w kierunku, w którym w danej firmie nie widzą przyszłości i wtedy pojawia się konflikt interesów.

Shelfie i inne projekty

W swojej ponad 13-letniej karierze testerskiej brałem udział w kilku projektach, w których wykorzystywane były nowe technologie. Zwykle były to dość krótkie przedsięwzięcia. Znacznie więcej czasu spędziłem w projektach legacy. Nie chcę przez to powiedzieć, że było w tym coś złego. W nich też się sporo nauczyłem. Wszystko tak naprawdę opiera się na odpowiednim nastawieniu. Takie są moje doświadczenia. Twoje mogą być zupełnie inne.

Jednym z ciekawszych był bez wątpienia projekt Shelfie. Pod tym linkiem znajdziesz krótki filmik na ten temat. Projekt składał się z dwóch aplikacji. Pierwsza to bot, który obsługiwał kilka scenariuszy biznesowych. Druga to aplikacja desktopowa, która wyświetlała obraz z kamery zamontowanej nad półką, na której umieszczane były przedmioty. Zadaniem aplikacji było wykrywanie tego, co zostało położone lub zabrane z półki. Było to możliwe dzięki zastosowaniu Computer vision oraz nauczeniu algorytmu rozpoznawania poszczególnych przedmiotów (owoce, produkty spożywcze, narzędzia). Algorytm uczył się na podstawie setek zdjęć każdego z produktów. Najciekawszy scenariusz umożliwiał grę w kółko i krzyżyk. Poza tym interesujące było to, że danymi testowymi były takie rzeczy jak: pepsi, czekolada, jabłko, śrubokręt, klucz, itp.

Tak jak pisałem powyżej, więcej czasu spędziłem w starszych technologiach. Na początku swojej kariery testowałem głównie aplikacje desktopowe z bazami danych. Były to projekty dla branży energetycznej. Następnie miałem okazję potestować trochę aplikacje webowe. Jedna dla sądownictwa, a druga dla Poczty Polskiej.

Później dużo było tematów związanych z bazami danych. Były to zwykle starsze wersje. W tych projektach miałem okazję znacząco rozwinąć moje umiejętności SQL.

Następnie kilka lat spędziłem w projekcie z czarnymi ekranami. Praca głównie odbywała się w konsoli, gdzie każdego dnia odpalałem skrypty kornshellowe oraz programy napisane w języku C. Tutaj również SQL bardzo się przydał. Było też sporo testów integracyjnych z innymi systemami, co stanowiło bardzo ciekawe doświadczenie.

Po kilku latach podjąłem decyzję o zmianie projektu. Dzięki temu znowu miałem możliwość testowania aplikacji webowej. Trwało to niestety tylko kilka miesięcy, ale była to bardzo ciekawa przygoda, dla której warto było porzucić czarne ekrany. Po pierwsze był to chyba największy projekt, w jakim brałem udział i jeden z lepiej zorganizowanych. W sumie projekt był realizowany przez pięć zespołów (2 x QE +4 x DEV). Tu też mogłem doświadczyć praktyk agilowych na wysokim poziomie. Działało to naprawdę imponująco.

Po tym, jak projekt się skończył, pojawiły się przede mną nowe możliwości. Zdecydowałem się spróbować czegoś z kompletnie innej beczki. Dołączyłem do zespołu, którego zadaniem było zbudowanie kompetencji w zakresie platformy Salesforce. Dzięki temu zdobyłem certyfikat Salesforce Administrator, a praca była dzielona pomiędzy testowanie oraz tworzenie aplikacji. To było niezwykłe doświadczenie.

Kolejnym etapem był powrót do projektu legacy. Testy niemal w stu procentach odbywały się na wiekowej już bazie danych (SQL jobs, store procedures). W tym przypadku wiedza o SQL znowu okazała się nieoceniona. Potem były jeszcze krótkie epizody w projektach frontendowych: aplikacja webowa typu PWA na telefony oraz desktopy, a także aplikacja hybrydowa na telefony.

Cechy testera

Czy każdy może zostać testerem? To jest pytanie, które dość często pojawia się na różnych forach i grupach związanych z testowaniem. Jest ono też istotnym przedmiotem rozważań różnych artykułów dotyczących testowania. Uważam, że są pewne cechy, które są ważne w tym zawodzie. Są też i takie, które pozwolą być naprawdę dobrym w tej profesji. Odpowiadając na pytanie, czy każdy może zostać testerem, mogę stwierdzić, że większość osób jest w stanie nim zostać, ale znacząco mniej osób jest w stanie nim być w dłuższej perspektywie. Tylko nieliczni mogą zostać mistrzami w tej dziedzinie.

Przyjrzyjmy się zatem tym cechom, które sprzyjają zostaniu testerem. Jedną z najważniejszych rzeczy w tym zawodzie jest ciekawość. Istotą pracy często bywa coś, czego nie pochwalamy w życiu prywatnym, czyli… szukanie dziury w całym. Umiejętność drążenia tematu, znajdowania drugiego czy kolejnego dna to bez wątpienia bardzo ważne zagadnienia.

Ściśle wiąże się to z komunikacją. Mam na myśli zarówno komunikację wewnątrz zespołu, jak i poza nim. W końcu tym dopytywaniem i drążeniem nie powinniśmy wyprowadzać z równowagi innych współpracowników. Przekazywanie informacji jest również bardzo istotne. W końcu to sedno naszej pracy, sedno, którym jest informowanie o jakości aplikacji, naszych spostrzeżeniach, ryzykach czy rekomendacjach co do kolejnych kroków. Dodam od razu, żeby rozwiać pewne wątpliwości, że praca w IT, to praca w zespole. A to oznacza współpracę i konieczność komunikacji z innymi. Jeśli więc marzysz o pracy indywidualnej i w spokoju, o tym, żeby nikt od Ciebie nic nie chciał, to nie jest to odpowiednie miejsce dla Ciebie. Zdecydowana większość zadań realizowana jest przez grupę osób, które dopełniają się kompetencjami i wiedzą. By być efektywnym, trzeba umieć się komunikować.

Ciekawość według mnie bardzo mocno łączy się jeszcze z chęcią eksploracji, odkrywania i przekraczania pewnych barier. Moim zdaniem trudno być dobrym testerem bez silnej potrzeby odkrywania tajemnic i „kombinowania z aplikacją”, by zobaczyć, co się stanie, gdy zejdzie się ze standardowej ścieżki i coś pomiesza. Każdy dobry tester jest jak poniższa mewa — kiedy widzi zakaz, to jest znak, że tam koniecznie trzeba zajrzeć, bo właśnie tam dzieją się najciekawsze rzeczy. Nie znam niestety autora tego zdjęcia, a chętnie pogratulowałbym mu uważności. Na obrazek trafiłem w internecie.

Często rozwiązania, nad którymi pracujemy, są skomplikowane. To czyni je atrakcyjnymi z punktu widzenia testowania, bo są pewnym wyzwaniem. Ta złożoność powoduje jednak, że niełatwo zorientować się, jak jedna zmiana wpłynie na całość procesu lub inne procesy. Tutaj właśnie bardzo przydają się kolejne umiejętności: analizowanie oraz dostrzeganie powiązań pomiędzy poszczególnymi funkcjonalnościami czy systemami.

Kolejnym ważnym aspektem pracy w IT jest duża zmienność, np. technologii, narzędzi, sposobu pracy i wielu innych. To wymaga pewnej zdolności dostosowywania się do zmiennych warunków. Konieczna jest też chęć ciągłej nauki. Czasami z projektu na projekt trzeba przyswoić sporo zagadnień, często także zmienia się domena biznesowa. Bez ciągłej nauki zostajesz w tyle. Jeśli uważasz, że będziesz uczyć się przez 3, 6 lub 9 miesięcy, żeby zostać testerem i marzysz, by ten okres nauki w Twoim życiu się skończył, to niestety muszę Cię rozczarować. Jeśli myślisz, że później będziesz już tylko pracować w projekcie, to jesteś w dużym błędzie. To dopiero początek nauki. Będzie tego więcej, dużo więcej!

Tutaj z pomocą może przyjść kolejna ważna cecha, mianowicie wytrwałość. Wytrwałość się przyda, ponieważ nie zawsze przyswajanie nowych tematów będzie proste jak bułka z masłem. Czasami będzie to spory wysiłek. Ta cecha okaże się ważna również w przypadku pracy w projektach, które nie są do końca zgodne z Twoimi preferencjami. Może tak być, jeśli chodzi o zadania, sposób pracy czy używane narzędzia. Czasami jednak wybór jest ograniczony. Niektóre zadania mogą nie być zbyt fascynujące, a w przypadku niektórych może pojawić się potrzeba wielokrotnego ich powtarzania. Bez wytrwałości może to nie być łatwe.

Przydaje się także chęć szukania usprawnień i analizowania tego, co poszło nie tak. Czasami zdarza się, że nie wyłapiemy jakiegoś istotnego defektu na etapie developmentu. Przyczyny mogą być różne. Warto jednak je zbadać i wyciągnąć wnioski na przyszłość. To jest zwykle cenna lekcja, którą polecam odrobić.

Jest jeszcze jedna ważna rzecz. Praca pod presją czasu. No cóż, w IT są terminy, w których coś trzeba dostarczyć klientowi. Czasami są one nieprzesuwalne i choć większość osób zaangażowanych widzi ryzyko związane z dostarczeniem rozwiązania na czas, w szczególności o pożądanej jakości, to i tak terminu trzeba dotrzymać.

Podstawy testowania

Czym jest testowanie?

Testowanie oprogramowania jest procesem związanym z wytwarzaniem oprogramowania. Polega na weryfikacji poprawności działania aplikacji. Może być przeprowadzone w oparciu o specyfikację i powinno sprawdzać zgodność systemu z wymaganiami użytkowników. Testowanie jest jednym z procesów zapewnienia jakości. Musisz wiedzieć, że testowanie samo w sobie nie podnosi jakości oprogramowania. Służy ocenie jakości, a także budowaniu zaufania do weryfikowanego produktu. Jakość natomiast może zostać podniesiona poprzez wprowadzenie poprawek i wyeliminowanie znalezionych błędów.

Proces testowania aplikacji może skupiać się na weryfikacji zaimplementowanych funkcjonalności, które zostały wytworzone w oparciu o wymagania użytkownika. Mówimy wtedy o testach funkcjonalnych. Często są też sprawdzane pewne cechy jakościowe systemu, które nie są związane z konkretną funkcjonalnością, jak chociażby bezpieczeństwo czy wydajność. W takim wypadku mówimy o testach niefunkcjonalnych.

Przypadki testowe (Test Cases)

Przypadki testowe są wciąż najczęściej przygotowywanym przez testerów rodzajem dokumentacji. Z tego powodu dość często możesz trafić na pytania dotyczące tego zagadnienia podczas rozmowy rekrutacyjnej. Warto zatem zgłębić ten temat. Jak zatem taki przypadek testowy powinien wyglądać i jakie elementy zawierać?

Zanim przejdziemy do przykładu, zajrzyjmy najpierw do definicji zaczerpniętej ze „Słownika wyrażeń związanych z testowaniem” SJSI.

Przykładowy przypadek testowy

Na potrzeby tego rozdziału oraz kolejnego, dotyczącego defektów, posłużę się zadaniem #20 z Mr Buggy 3. Przygotuję do niego przykładowy przypadek testowy, żeby zademonstrować, jak może wyglądać. Zgodnie z ideą tej książki, nie jest to jedyne słuszne podejście, bo takie nie istnieje. Mimo tego poniższy przykład powinien dać Ci pewien pogląd na to zagadnienie.

Treść zadania:

Zadanie przedstawia funkcję wysyłania przelewów w internetowym koncie bankowym. Odszukaj i zgłoś defekt.

Przykładowe poprawne numery rachunków:

1) 83109069928729691303181767

2) 97116052168159436723349207

3) 33102022251281637642546453

4) 63102085042134478184474438

5) 61102064838251962701343051.

Przykładowe niepoprawne numery rachunków:

1) 89105024841488137640364928

2) 89105024841488147640364345

3) 99103024841488147640384345

4) 99102024841488135640364345

5) 99102024846666135640364345.

Pola oznaczone gwiazdką są wymagane. Rozłożenie pól i przycisków jest zgodne z wymaganiami klienta.

Spójrz jeszcze na to, jak wygląda formularz.

Przypadek testowy do powyższego zadania może wyglądać jak poniżej.

Poza tym, co zawarte jest w powyższej tabeli, mogą też pojawić się dodatkowe elementy. Jednym z nich jest priorytet, którym można określić, które z testów powinny zostać wykonane w pierwszej kolejności. To może się przydać, np. kiedy brakuje czasu na wykonanie wszystkich zaplanowanych wcześniej testów. Wtedy zyskujemy możliwość wybrania zestawu najistotniejszych przypadków i pominięcia tych najmniej krytycznych (z niższym priorytetem).

W trakcie wykonywania testów mogą pojawić się także informacje związane ze środowiskiem (np. TEST, UAT, SIT), na którym przypadek został wykonany. Istotne będzie też to, na jakiej wersji aplikacji test powinien zostać wykonany oraz na jakiej konfiguracji, np. na której przeglądarce, systemie operacyjnym czy rozdzielczości ekranu.

Warto też wiedzieć, że jest sporo narzędzi, które można wykorzystać jako repozytorium testów. To w nich tworzone i przechowywane są przypadki testowe, które później czekają na ich wykonanie. Więcej informacji o narzędziach znajdziesz w rozdziale „Narzędziownia”.

Egzekucja testów

Egzekucja testów (test execution) polega na wykonaniu kroków zdefiniowanych w test case, a następnie nadaniu odpowiedniego statusu w narzędziu. Status zależy od otrzymanego wyniku testu. Najczęściej spotykane statusy to:

— to do — test został zaplanowany i czeka na wykonanie

— executing/in progress — oznacza, że dany przypadek jest w trakcie wykonywania

— passed — w momencie kiedy test przechodzi bez problemu

— failed — gdy rezultat aktualny jest inny niż oczekiwany. W takim przypadku powinien zostać zgłoszony błąd. Zgłoszenie defektu zostało opisane w kolejnym podrozdziale. Większość narzędzi pozwala na powiązanie defektu z test casem, w trakcie wykonania którego został wykryty

— blocked — status używany w przypadku, gdy wykonanie danego testu jest niemożliwe w danym momencie.

Odpowiednie oznaczenie statusów pozwala na śledzenie postępu prac. Na bazie zgromadzonych w ten sposób danych można też budować różnego rodzaju metryki (np. przypadki testowe wg statusu wykonania, przypadki testowe wg priorytetu), wizualizacje. To pozwala lepiej zobrazować status wykonania testów oraz ułatwia przekazanie informacji na temat jakości osobom zainteresowanym. Przykładowe metryki zostały opisane w oddzielnym rozdziale.

Po co komu przypadki testowe?

Wiesz już, jak może wyglądać test case. Teraz czas na małą dygresję, która, mam nadzieję, rzuci trochę więcej światła na podejście do ich tworzenia. Czy zatem podczas pracy w projekcie trzeba pisać przypadki testowe?

Cytując Maxa, bohatera jednego z moich ulubionych filmów „E=mc2”, mogę stwierdzić, że:

bo to zależy. Ci, którzy mają już trochę doświadczenia, zapewne wiedzą, o czym mówię. Wpływ na to ma wiele czynników (wymienionych poniżej) i kontekst, w jakim przyjdzie Ci pracować. To samo tyczyć się może innych dokumentów testerskich, takich jak Test Plan czy Test Raport.

Co ma wpływ na naszą pracę?

— Organizacja, w której pracujesz — możesz spotkać się z sytuacją, w której