Bezpłatny fragment - Pasja Testowania

Wydanie pierwsze

© Copyright — Bugfree Krzysztof Jadczyk, Krzysztof Jadczyk, 2019

Korekta — Małgorzata Woźna

bugfreeblog.com

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

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 (możesz też zeskanować poniższy kod). 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 Twoja firma będzie miała zdefiniowane Test Policy, Test Strategy albo ogólny Proces testowy. Z tych dokumentów może wynikać, że przypadki testowe powinny być przygotowywane.

— Klient, dla którego projekt jest realizowany — sam klient też czasami wymaga dostarczania pewnej dokumentacji związanej z testami. Powody bywają różne: od braku zaufania do naszych testów, po konieczność dokumentowania całego procesu wytwarzania oprogramowania. Może być to podyktowane potrzebami jego klientów lub audytów związanych z certyfikacją. Czasami warto przypadki przygotować jako dowód tego, co zostało zrobione, w razie gdyby klient powiedział „sprawdzam”.

I tutaj mała gwiazdka. Czasami możesz spotkać się z taką sytuacją — dla klienta oznaczenie przypadku testowego na pass może nie być wystarczające. Pojawia się jeszcze pojęcie test evidence, które oznacza dostarczenie dodatkowej informacji, np. zrzutu ekranu, logów lub innego dowodu wykonania testu. Najczęściej taki dowód powinien przedstawiać rezultat oczekiwany, ale może też być potrzebny bardziej szczegółowy z uwiecznieniem wyniku dla każdego kroku.

— Czas trwania projektu — gdy masz do czynienia z krótkim projektem, to może nie być czasu ani sensu inwestować w przypadki testowe. Wtedy lepiej skupić się na testach eksploracyjnych niż tracić cenne godziny na dokumentowanie każdego kroku. Dla dłuższych projektów warto zdefiniować sobie chociażby regresję lub inne powtarzalne testy. Przygotowane przypadki mogą też być bazą do ich automatyzacji.

— Wiek testowanego systemu — możesz mieć okazję (tak jak ja kiedyś) pracować ze starym systemem tzw. legacy, gdzie jedyną dostępną dokumentacją jest kod aplikacji, a wiedza na temat poszczególnych funkcjonalności bywa mocno ograniczona. W takim wypadku zdobycie informacji na temat tego, jak coś działa i jak to przetestować, jest bardzo czasochłonne. Należy pilnować, by wysiłek nie poszedł na marne. Trzeba więc udokumentować jego rezultaty, np. w postaci przypadków testowych, wiki lub testów automatycznych.

— Metodyka, w której projekt jest realizowany — jeśli masz do czynienia z pracą w sprintach, które kończą się sukcesem, to na początku kolejnego powinieneś mieć wolną chwilę, zanim jeszcze dostaniesz coś nowego do testów. Ten czas można wykorzystać na przygotowanie test casów lub napisanie testów automatycznych.

— Twoje doświadczenie — sam dobrze wiesz lub po pewnym czasie będziesz wiedział, czego potrzebujesz, by Twoja praca była efektywna. Przypadki testowe mogą pomóc dostarczyć zainteresowanym osobom potrzebnych informacji na temat testowanej aplikacji. Na ich bazie można przygotować metryki pokazujące np. liczbę planowanych i wykonanych test casów, liczbę tych, które zakończyły się sukcesem i tych, które nie przeszły. Takie metryki mogą być przygotowane dla całej wersji aplikacji, poszczególnych funkcjonalności lub wymagania.

Czy zatem warto pisać przypadki testowe?

Podsumowując, to czy i jaką dokumentację będziesz przygotowywać, może być narzucone lub zależeć od Ciebie, ale bardzo silnie zależy od kontekstu. Jest to zdecydowanie dobra metoda na spisanie zdobytej wiedzy na temat testowanej aplikacji. Może też pomóc w rozpoczęciu automatyzacji, bo będziesz mieć już opisane scenariusze, które można później oskryptować.

W ten sposób udokumentujesz też testy, które wykonałeś. Możesz wykorzystać tę dokumentację jako dowód, gdy później coś się wysypie. Przypadki testowe mogą się też przydać w procesie wprowadzania nowych członków zespołu do projektu lub gdy będziesz potrzebować chwilowego wsparcia, np. podczas regresji. Jeśli nikt nie narzuca konkretnej formy dokumentacji, warto rozważyć mapy myśli, które zdecydowanie się sprawdzają.

Czasami jednak możesz mieć okazję realizować projekt dla klienta, który nie wymaga dostarczenia jakiejkolwiek dokumentacji. Podobnie może być w przypadku firm produktowych, w których sposób pracy zależy w dużej mierze od upodobań zespołu. Wtedy warto rozważyć, czy inwestować czas w pisanie test casów, czy raczej skupić się na testowaniu. Jak pisze Michael Bolton na swoim blogu, test case to nie testowanie.

Zgłoszenie defektu

Po przeczytaniu kilku poprzednich stron wiesz już, jak powinien wyglądać przypadek testowy. Kolejnym etapem w pracy testera może być wykonanie testu i zaraportowanie błędów w momencie zaobserwowania anomalii. Jak powinno wyglądać takie zgłoszenie i jakie elementy zawierać? O tym za chwilę. Zajrzyjmy ponownie do „Słownika wyrażeń związanych z testowaniem” SJSI i sprawdźmy definicję defektu.

Definicja definicją, a życie życiem. Często możesz spotkać się z pojęciami takimi jak defekt oraz błąd (bug), które chociażby według ISTQB to osobne zagadnienia. W życiu codziennym jednak te pojęcia są używane zamiennie i oznaczają nieprawidłowe zachowania systemu. Zwykle możemy mówić o błędzie w działaniu aplikacji, gdy testowana funkcjonalność zachowuje się niezgodnie ze zdefiniowanymi wymaganiami.

Poniżej znajdziesz przykład zgłoszenia defektu. Najpierw jeszcze kilka słów o tym, dlaczego tak ważne jest, aby dbać o jakość zgłoszenia. Jest to istotne ze względu na zespołowy charakter pracy. Takie zgłoszenie, zanim zostanie zamknięte, może przejść przez kilka osób. Czasami może się zdarzyć tak, że są to osoby, które nie znają tej części aplikacji, której błąd dotyczy. Warto więc zadbać o to, by opis był zrozumiały dla każdego. Uwierz mi, Tobie też to pomoże w momencie, kiedy błąd trafi do Ciebie do retestów po kilku tygodniach lub miesiącach od zgłoszenia. Warto wiedzieć, że niektóre zgłoszenia mogą być przeglądane przez klienta w trakcie spotkania Defect Triage. Wtedy także dokładny i zrozumiały opis jest bardzo przydatny.

Poniżej znajdziesz przykład zgłoszenia błędu. Przytoczony defekt został wykryty podczas wykonania przypadku testowego podanego w rozdziale wcześniej. Błąd dotyczy zadania #20 w aplikacji Mr Buggy 3.

Najważniejsze informacje, które powinno zawierać poprawne zgłoszenie błędu, wymieniłem powyżej. Poza tym przydadzą się też różne załączniki: logi, screeny albo nawet filmiki. Te ostatnie dopiero niedawno zacząłem bardzo doceniać. W jednym z projektów testowałem rozwiązanie dostarczane przez zewnętrzną firmę. Była to dla mnie nowość przede wszystkim dlatego, że nie miałem możliwości bezpośredniego kontaktu z programistami. Komunikacja była więc bardzo ograniczona, przez co jakość zgłoszeń była niezwykle ważna. Mówi się, że jeden obraz wart jest więcej niż tysiąc słów. Filmiki rzeczywiście ułatwiały zgłoszenie defektów zwłaszcza przy bardziej skomplikowanych ścieżkach i czasami trudnym do opisania zachowaniu aplikacji.

Powyżej wymieniłem najbardziej powszechne elementy zgłoszenia. W praktyce często dodaje się jeszcze inne istotne informacje:

— faza testów, w której błąd został wykryty, np. UAT (User Acceptance Tests), SIT (System Integration Tests), development

— czy błąd został znaleziony przez testy automatyczne czy manualne

— z jakim typem wymagań błąd jest związany, np. funkcjonalne, bezpieczeństwa, wydajności.

Informacje te mogą pojawiać się w formie tagów lub labelek w zależności od użytego narzędzia. Posiadanie tych danych pozwala na bardziej zaawansowane analizy występowania błędów.

Severity vs Priority (Ważność vs Priorytet)

Jak pewnie zauważyłeś, w zgłoszeniu defektu pojawiają się takie atrybuty jak Priorytet oraz Ważność. Czas wyjaśnić, czym są te atrybuty i jaka jest między nimi różnica.

Priorytet błędu określa kolejność, według której błędy powinny być poprawiane. Niektóre defekty mogą blokować testowanie danej funkcjonalności. W takim przypadku, nadając najwyższy priorytet, możemy przekazać reszcie zespołu informację, że poprawka tego błędu powinna zostać dostarczona w pierwszej kolejności. Przykładowe priorytety zostały przedstawione na wykresie w podrozdziale dotyczącym metryk — Blocker, Critical, Major, Minor.

Ważność błędu określa, jak bardzo problem jest istotny z punktu widzenia biznesu. Jego wartość jest często powiązana ze stratami finansowymi lub wizerunkowymi. Przykładowe wartości to: Critical, Major, Minor.

Często krytyczny priorytet przekłada się na ważność na poziomie krytycznym, ale nie zawsze tak jest. Spójrz na przykłady poniżej.

Priorytet = krytyczny, Ważność = niska

Przykładem takiego błędu może być niewłaściwe logo na stronie głównej testowanej aplikacji. Z jednej strony nie powoduje to problemu w używaniu aplikacji, ale może wpłynąć na wizerunek firmy.

Priorytet = niski, Ważność = wysoka

Załóżmy, że testujesz aplikację, w której nie działa funkcjonalność wykorzystywana pod koniec roku kalendarzowego. Przeprowadzasz testy w połowie roku. Fakt, że nie działa ważna część systemu, powoduje, że ważność jest wysoka, ale ze względu na dużą ilość czasu defekt może zostać poprawiony w kolejnej wersji.

Lista używanych wartości dla obu parametrów może się różnić w przypadku różnych organizacji. Może też zależeć od użytego narzędzia, które ma zdefiniowane pewne domyślne ustawienia. Często wartości te są konfigurowalne.

Zapamiętaj powyższe przykłady oraz poszukaj więcej w internecie. To zagadnienie dość często pojawia się na rozmowach rekrutacyjnych.

Cykl życia defektu

Poniżej znajdziesz diagram z Jiry przedstawiający przykładowy cykl życia defektu. Dlaczego przykładowy? Tak jak już wspominałem na kartach tej książki, nie ma jednej sprawdzonej odpowiedzi na to pytanie. Cykl życia może się znacząco różnić między organizacjami i zespołami. Z pewnością po wpisaniu takiego hasła w wyszukiwarce pojawi się wiele różnych diagramów. Być może każdy z nich sprawdza się lepiej w innej sytuacji. Nie ma to jednak większego znaczenia dla dalszych rozważań. Warto wiedzieć, że tak jest. Tak samo jak to, że błędy mogą być zgłaszane przez dowolnego członka zespołu, a nie tylko przez testera. Zresztą będziesz mieć też do czynienia ze zgłoszeniami od klienta. Te są zwykle bardzo ciekawe, ale nie będę zdradzał tajemnicy. Po prostu trzeba samemu przez to przejść.

Wróćmy jednak do diagramu i przeanalizujmy, co się na nim dzieje.

— Zgłoszony defekt na początku swego życia ma status Open.

— W kolejnym kroku może on zostać zamknięty (Closed) albo programista zacznie nad nim pracować (In progress). Jeśli przyjrzysz się dokładniej, zauważysz, że błąd może zostać zamknięty z poziomu wielu statusów. Powody mogą być różne, np.: zgłoszenie jest duplikatem; po dyskusji z analitykiem lub klientem okazuje się, że to nie jest błąd; defekt jest stary i został poprawiony przy okazji innych zmian; nie da się zreprodukować defektu.

— Programista zmienia status na Ready To Test w momencie, gdy błąd został poprawiony i można przystąpić do retestów.

— Status Testing oznacza, że błąd jest w trakcie weryfikowania.

— Jeśli w trakcie retestów okazuje się, że błąd nadal występuje, to tester oznacza go jako Reopened i cała zabawa zaczyna się od nowa.

— Jeśli jednak błąd został poprawiony, tester zmienia jego status na Resolved. W tym statusie błędy zwykle czekają na wdrożenie danej wersji z poprawkami i dopiero wtedy status zmieniany jest na Closed.

Defect Triage

W trakcie trwania projektu mogą pojawić się spotkania Defect Triage. Rozróżnić można dwa typy: wewnętrzne, w których udział biorą tylko reprezentanci zespołu, oraz zewnętrzne, w których udział bierze także ktoś powołany przez klienta. Jest to zwykle spotkanie pomiędzy analitykiem, testerem lub test managerem, a także reprezentantem klienta w przypadku tych drugich. Celem spotkania jest przegląd zgłoszeń i weryfikacja ich priorytetów, czyli ustalenie kolejności ich poprawiania. Z jednej strony jest to dobre miejsce do tego, by uświadomić klientowi liczbę otwartych defektów. Z drugiej jest to okazja do ustalenia konkretnych akcji dalszych działań związanych z poprawianiem i dostarczaniem poprawek. Jest to niezwykle ważne, ponieważ czasami możemy nie być świadomi tego, jak bardzo krytyczny jest dany błąd i jak bardzo wpływa on na efektywność pracy użytkowników aplikacji. Można się dzięki temu dowiedzieć więcej na temat samego biznesu.

Czasami zdarza się tak, że klient naciska na dostarczanie nowych funkcjonalności. Jest to zrozumiałe, ponieważ nowe funkcjonalności mogą rozwiązywać konkretne problemy ludzi używających aplikacji, przyspieszać lub ułatwiać im pracę. Czasami aplikacja jest sprzedawana klientom naszego klienta. W takim przypadku istotne może być pokazanie postępu prac w produkcie. Czasami ten nacisk na kolejne funkcjonalności jest tak duży, że klient poniekąd lekceważy potrzebę poprawy błędów, czasami nie zdając sobie sprawy z ich liczby oraz wagi. W tym przypadku spotkania defect triage mogą okazać się bardzo przydatne w budowaniu świadomości na temat liczby i powagi istniejących zgłoszeń. Może to się przełożyć na pewną zmianę podejścia klienta i decyzję o poprawianiu przynajmniej krytycznych błędów.

Metryki

W tym rozdziale zapoznasz się z przykładowymi metrykami. Te, które prezentuję, są dość podstawowe, ale jednocześnie bardzo przydatne i najczęściej wykorzystywane. Dlatego właśnie warto je znać.

Użyte przeze mnie poniżej statusy czy nazwy priorytetów są przykładowe. W swoim projekcie możesz spotkać zupełnie inne. Czasami zależą one od używanego narzędzia lub przyjętej konwencji nazewniczej w danej organizacji.

Metryki dotyczące statusu wykonania testów

— przypadki testowe wg statusu wykonania

Metryki dotyczące defektów

— defekty wg priorytetów

— błędy wg statusu

— Traceability matrix — pozwala na zwizualizowanie i śledzenie pokrycia wymagań oraz statusu wykonania testów. Taki diagram zwykle jest dostępny w narzędziach do zarządzania testami. Poniżej znajdziesz przykład tego, jak to może wyglądać. Podane przeze mnie dane w Twoim projekcie mogą wyglądać inaczej. Jak widać w tabelce poniżej, traceability matrix pozwala zobaczyć, jak wymaganie jest powiązane z konkretnymi przypadkami testowymi, które testują to wymaganie. Matryca zawiera też status wykonania testów. Niektóre z test casów mają więcej niż jeden status wykonania, ponieważ mogły być przeprowadzone kilka razy, np. w różnych cyklach testowych. Część tego typu metryk pokazuje także defekty, które zostały wykryte w trakcie testów.

Sztuka estymacji

Z tego rozdziału dowiesz się, jakie aktywności należy uwzględniać w wycenie pracy. Dostaniesz także kilka cennych wskazówek mówiących o tym, o czym warto pamiętać, przekazując informacje o estymacji innym osobom.

Z wyceną naszej pracy spotykamy się na różnych etapach życia projektu. Zaczyna się zwykle od pierwszej estymacji w czasie tworzenia oferty (proposal). Następnie przeliczamy wszystko jeszcze raz po wygraniu projektu, kiedy znamy więcej szczegółów, a jeszcze później wyceniamy poszczególne user stories podczas sesji planingowych (sprint planning w przypadku agile — więcej na ten temat w kolejnym rozdziale).

Sama estymacja, w zależności od etapu czy specyfiki pracy w projekcie lub organizacji, może być przygotowywana w różnych jednostkach: story pointach, godzinach, MD (man days), które następnie przeliczane są na pieniądze.

— Faza sprzedażowa (pre-sale) — projekt jest zwykle estymowany w story pointach. Na tym etapie często pojawia się sporo założeń, które mogą dotyczyć całego projektu lub jakiegoś wymagania. Na podstawie pozyskanej od klienta wiedzy lub różnych dokumentów przygotowywana jest lista funkcjonalności. W przypadku projektów agilowych (więcej informacji znajdziesz w późniejszym rozdziale) funkcjonalności są opisane w formie user story. Często grupuje się je w epiki, które mogą reprezentować jakiś moduł aplikacji, np. logowanie, zarządzanie użytkownikami itp. Poszczególne user story estymowane są w pierwszej kolejności w story pointach, które odzwierciedlać mają stopień złożoności. Jednym z podejść jest wybór kilku reprezentantów z poszczególnych grup (wyestymowanych na 1, 2, 3, 5 itd. story pointów), rozbicie ich na zadania (task breakedown) oraz wyestymowanie ich w godzinach. Celem tego ćwiczenia jest z jednej strony zweryfikowanie, czy estymacja w story pointach jest poprawna. Z drugiej strony wyznacza się pewien współczynnik (godziny / 1 story point), który pozwoli na wyliczenie kosztu projektu w pieniądzach.

— Refinement meeting (opis znajdziesz w rozdziale o agile) — omawiane są poszczególne user story i wyjaśniane wątpliwości. Znając więcej szczegółów, ponownie estymuje się w story pointach.

— Planning meeting — w trakcie tego spotkania user story zostaje podzielone na konkretne zadania do zrobienia, a każde z nich wycenia się w godzinach.

Na etapie sprzedażowym może pojawić się także zarys kształtu zespołu, czyli ról i stopień ich zaangażowania, żeby zrealizować projekt. Opis ról projektowych znajdziesz kilka rozdziałów dalej. Część z firm, by przyspieszyć proces wyceny projektu, estymuje tylko zadania developerskie. Pozostałe zostają wyznaczone na podstawie przyjętych współczynników (ratio), wykorzystując w ten sposób wiedzę z poprzednich projektów. Jednym z takich współczynników jest liczba developerów w stosunku do liczby testerów w zespole. Może to być np. 5:2, 3:1 lub nawet 3:3. Zależy to od wielu czynników.

Ale co uwzględniać w estymacjach?

Wszystko! Wycena samych testów funkcjonalnych to za mało.

— Dokumentacja — należy dodać czas na przygotowanie dokumentacji (test case, test plan, test report). Ilość potrzebnej dokumentacji będzie zależna od sposobu naszej pracy oraz od wymagań klienta. Pisałem o tym w poprzednim rozdziale.

— Dane testowe — nie należy zapominać o przygotowaniu danych testowych. W przypadku niektórych funkcjonalności może to być bardzo czasochłonne.

— Testy niefunkcjonalne — warto pomyśleć, które z testów performance, security, accessibility, disaster recovery itp. mogą być potrzebne w danym projekcie. Oczywiście warto znać wymagania (NFR — non-functional requirements), które należy spełnić. Bez tego trudno przygotować estymację, można przyjąć jakieś założenia, a później je zweryfikować, gdy będziesz znać więcej szczegółów. Założenia powinny być jawne i dostarczone razem z estymacją, by dawać pełny obraz.

— Testy automatyczne — jeśli zakładasz testy automatyczne w projekcie, to potrzebny będzie też czas na wybranie odpowiedniego narzędzia, konfigurację frameworka oraz CI. To wszystko trzeba dodatkowo uwzględnić poza samym czasem pisania testów oraz czasem na ich utrzymanie. Oczywiście do tego będzie potrzebne przyjęcie strategii samej automatyzacji. Dobrze jest też określić, które z testów (unit test, integration test, end to end) będą pokryte przez testerów, a które przez developerów.

— Test Management — w niektórych projektach będzie to kluczowe. Komunikacja z klientem lub też z innymi dostawcami ma często bardzo duży wpływ na projekt, dlatego warto pamiętać, by uwzględnić ten czas w estymacji.

— Inne fazy testów — oczywiście należy uwzględnić też czas na ewentualne systemowe testy integracyjne, testy UAT itp. Ich zakres będzie zależał od specyfiki projektu.

— Cross-browser testing — w przypadku aplikacji webowych należy też pamiętać o wykonaniu testów pod różnymi przeglądarkami, zwłaszcza gdy aplikacja jest otwarta na świat. Czasami będzie tak, że klient określi, na jakich przeglądarkach i na jakich wersjach aplikacja ma działać. Czasami jednak tej informacji może nie dostarczyć. Wtedy warto sprawdzić informację o udziale w rynku poszczególnych przeglądarek w kraju, gdzie dana aplikacja będzie używana — więcej na ten temat w rozdziale „Jak się do tego zabrać?”.

— Testy na urządzeniach mobilnych — podobnie jak z przeglądarkami, jeśli mamy do czynienia z aplikacją webową, to o ile nie ma dedykowanej aplikacji natywnej, warto też stronę sprawdzić na różnych urządzeniach mobilnych pod różnymi systemami i ich wersjami. W tym przypadku znowu przydadzą się informację o udziale w rynku poszczególnych wersji Androida i iOS. Kluczowa może też być rozdzielczość ekranu. Więcej na ten temat w rozdziale „Jak się do tego zabrać?”.

— Inne czynności specyficzne dla danego projektu, np. testy migracji danych.

Czy to wszystko?

Poza elementami wymienionymi powyżej warto wypracować sobie pewne podejście do samego estymowania. W przypadku bardziej wymagających tematów lepiej sprawdzić się może przedział, np. 20—25 dni zamiast jednej wartości. Czasami stosuje się też poziom niepewności dla poszczególnych wycenianych elementów. Do tego należy dodać informację o przyjętych założenia oraz ryzykach.

Przygotowanie estymacji to bardzo ważny element pracy testera. Warto się w nią zaangażować, by mieć wpływ na ilość czasu przeznaczonego na testy. Jest sporo rzeczy, o których trzeba pamiętać, by wszystko uwzględnić, a pominięcie jakiegoś elementu może mieć negatywne konsekwencje na projekt. W tym celu można przygotować sobie check listę, z której skorzystasz w czasie przygotowywania estymacji.

Dobrym zwyczajem jest też estymowanie niezależnych rzeczy osobno i podawanie tej informacji jawnie, np. testy automatyczne, performance, dokumentacja itp. W takim przypadku dajemy klientowi możliwość zrezygnowania z dowolnej aktywności, jeśli będzie chciał obniżyć koszty. Dzięki takiej transparentności łatwiejsze powinno być podjęcie decyzji dotyczącej tego, co obciąć i jednocześnie będzie wiadomo, czego nie dostarczymy. Może to też pomóc uzasadnić podawane liczby, jeśli będziemy w stanie wytłumaczyć, co się pod nimi kryje.

Sztuka estymacji nie jest prosta, zwłaszcza na początku, kiedy nie ma się w tym doświadczenia. W takim przypadku proponuję śledzić własne szacunki, żeby wiedzieć, kiedy rozmijasz się z rzeczywistością. Daje to też możliwość wyciągania wniosków na przyszłość i uczenia się na kolejnych przypadkach. Z czasem powinno Ci to iść coraz lepiej, a celność podawanych wartości powinna być lepsza z każdym przećwiczonym przypadkiem.

Jeśli będziesz mieć możliwość estymowania zadań i będziesz to robić pierwszy raz, to przygotuj sobie prostego Excela. W pliku możesz wypisać poszczególne zadania, które uwzględniasz w estymacji. Możesz też to oczywiście zrobić bezpośrednio w narzędziu, w którym estymacje umieścisz pod konkretnymi zadaniami. W trakcie pracy śledź czas, jaki spędzasz nad ich realizacją. Notuj też pewne aspekty, które mają wpływ na czas wykonania, a o których nie wiedziałeś lub nie pomyślałeś wcześniej. Wtedy możesz w łatwy sposób zasygnalizować, że wykonanie zadania może się opóźnić, bo pojawiły się nowe okoliczności. Przyda Ci się to także w kolejnym podejściu do przygotowania estymacji i być może sprawi, że będą dokładniejsze.

Checklisty estymacyjne

Dla czynności powtarzalnych warto sobie wypracować sposób, który pomoże pamiętać o wszystkich elementach. Z własnego doświadczenia wiem, że jak się coś powtarza wiele razy, łatwo zapomnieć o pewnych oczywistych rzeczach. W przygotowaniu estymacji mogą pomóc checklisty, przez które można przejść, gdy trzeba coś oszacować. Poniżej przygotowałem dwie przykładowe. Pierwsza pod estymację user story, druga do estymowania całego projektu.

Testy eksploracyjne

Testy eksploracyjne są coraz bardziej popularną techniką testowania aplikacji. Testy te polegają na uczeniu się aplikacji w trakcie weryfikacji określonej funkcjonalności. W tym przypadku nie powstają przypadki testowe, które następnie są wykonywane. Takie testy świetnie sprawdzają się w przypadku braku dokumentacji opisującej działanie aplikacji. Dobrze z nich skorzystać także wtedy, gdy ilość czasu na testy jest bardzo ograniczona. Takie podejście pozwala na szybkie wykrycie błędów, ponieważ nie traci się czasu na przygotowanie przypadków testowych przed wykonaniem właściwych testów. Tutaj od razu przystępuje się do sprawdzania wybranego zakresu aplikacji.

Session-based Test Management

Jedną z metod wykonywania testów eksploracyjnych jest Session-based Test Management opisany przez Jonathana i Jamesa Bacha w roku 2000. Testy przeprowadzane są w sesjach (inaczej mówiąc są time-boxowane) o określonym czasie trwania — krótkie 45 minut, długie 120 minut. Takiemu podejściu przyświeca kilka założeń opisanych poniżej.

— Sesja ma zdefiniowaną misję, czyli określone jest to, co podlega testowaniu lub na jakim problemie tester będzie się skupiał.

— Sesja nie jest przerywana przez spotkania, rozmowy, telefony lub maile.

— W trakcie sesji powstają notatki, które zawierają: opis tego, co zostało sprawdzone, listę znalezionych błędów, zaobserwowane odstępstwa, ryzyka.

Poniżej znajdziesz przykładowy rezultat sesji eksploracyjnej, który został zaczerpnięty z podlinkowanego wcześniej artykułu.

Często, gdy czytałem o testach eksploracyjnych, pojawiała się informacja, że takie testy wykonywane są przez doświadczonych testerów. Podkreślane było, że takie osoby mają już pewną intuicję i na bazie swojego bagażu doświadczeń wiedzą, na czym się skupiać, gdzie szukać ryzyk. Trudno się z tym nie zgodzić, ale myślę, że jest też druga strona medalu zwanego eksploracją. Przy ograniczonej ilości czasu nawet osoba o małym doświadczeniu powinna wybrać taką technikę. W takim przypadku nie będzie możliwe zapoznanie się z dokumentacją (o ile taka w ogóle istnieje). Nie warto tracić cennego czasu na pisanie przypadków testowych. Co lepiej sprawdzi się w takiej sytuacji? Eksploracja jest najlepszym rozwiązaniem. Pamiętaj, że Twoją rolą nie jest znalezienie i zarejestrowanie jak największej liczby błędów, a przekazanie informacji na temat jakości aplikacji. Nie ocenisz tego, pisząc przypadki testowe. Tylko uruchomienie aplikacji pozwoli Ci doświadczyć jak funkcjonuje, czy da się jej używać i przejść zaimplementowany proces biznesowy. W takim przypadku, gdy Twoja wiedza na temat aplikacji jest mała, możesz poprosić kogoś z zespołu o krótkie wprowadzenie. Uważam, że skupienie się na aplikacji będzie dużo lepsze i dostarczy większą wartość niż pisanie jakiejkolwiek dokumentacji.

Nauka testowania

Crowdtesting

Od czego zacząć naukę testowania oprogramowania?

Przeglądając wiele blogów i postów na ten temat, zauważyłem, że najczęściej pojawia się kilka źródeł, z których można czerpać wiedzę. Z częścią z nich możesz zacząć naukę w zaciszu domowym i we własnym tempie (książki, blogi, strony internetowe, kursy online, webinary czy crowdtesting). Inne (szkolenia, warsztaty, staże, praktyki) mogą wymagać dostosowania się do terminów, miejsca i formy ich prowadzenia.

Zachęcam, by dobierać metody i sposób uczenia się do własnych preferencji, by proces ten był najbardziej efektywny jak to tylko możliwe. Warto wykorzystać w tym celu cykl Kolba dotyczący uczenia się dorosłych.

Crowdtesting jako jedna z metod

Jedną z ciekawych i cieszących się coraz większą popularnością metod jest metoda crowdtestingu. Według mnie jest to jedna z lepszych metod do rozpoczęcia przygody z testowaniem. Może być to dobry sposób nauki dla osób, które lubią praktykę. Jeśli ktoś miałby ochotę zacząć od tego, może skorzystać z takich stron jak utest.com czy www.test.io. Ja wypróbowałem utest.com.

Jest to dobry sposób, aby doświadczyć testowania aplikacji zarówno webowych, jak i mobilnych na Androida/iOS i aby zwiększyć swoją wiedzę w tym zakresie. Można też nauczyć się zgłaszania błędów wg ściśle zdefiniowanego sposobu (przy okazji zdobywając wiedzę na temat dołączania logów z developer toolsów z przeglądarki, a także z telefonów). Trzeba jednak zdawać sobie sprawę, że podejście do raportowania błędów zaproponowane na utest.com nie jest jedynym słusznym i że nie musi ono być efektywne w każdym projekcie komercyjnym.

Co jeszcze zyskasz przez crowdtesting?

Udział w projektach na utest warto też wykorzystać do przeglądania błędów zgłoszonych przez inne osoby, które są zwykle udostępniane po zakończeniu danego Test Cycle. Pozwala to wyciągnąć wnioski o obszarach, które być może w naszych testach pominęliśmy, by dzięki temu usprawnić nasze podejście do testowania w kolejnym Test Cycle.

Nie tylko testowanie

W ramach udziału w projektach możesz zostać też poproszony o wypełnienie formularza Review, gdzie w rozbudowany sposób powinieneś wypowiedzieć się na temat swoich wrażeń odnośnie testowanej aplikacji. Formularz dotyczy takich aspektów aplikacji jak: Usability and Design, Features and Functionality, Performance, Pros and Cons. Jest to fajny sposób do wyrobienia w sobie nawyku nieograniczania się tylko do samego testowania, ale ogólnej oceny testowanej aplikacji i szerszego spojrzenia. To bardzo przyda się w przyszłości.

Udział w projektach typu crowdtesting może też być wynagrodzony finansowo za zgłoszone błędy. Celowo pomijam jednak ten fakt, gdyż w pierwszej kolejności zalecam skupienie się na budowaniu wiedzy na temat testowania. Przy zaangażowaniu się w tego typu aktywność, pamiętaj też o dokumentowaniu zdobytej wiedzy. To będzie cenna informacja w kontekście przygotowywania CV i udziału w rozmowach rekrutacyjnych. Bez doświadczenia komercyjnego warto mieć jakiś atut, który może przesądzić o zaproszeniu do udziału w rekrutacji. Spis umiejętności nabytych w trakcie takich testów będzie bazą, na której można coś zacząć budować. Dodaj do tego informacje na temat liczby cykli testowych, ich zakresu (mobile, web, może branże aplikacji), liczby uznanych błędów i już będzie to jakiś zalążek do rozmowy o Twoich osiągnięciach. Poza tym będzie to informacja o Twoim zaangażowaniu i pokazanie realnego zainteresowania testowaniem. Zawsze to więcej niż tylko wiedza teoretyczna.

Ucz się testowania z Mr Buggym

Kolejnym fajnym sposobem na naukę na żywym organizmie jest skorzystanie z gotowych aplikacji. Mr Buggy jest bohaterem wszystkich zawodów w testowaniu oprogramowania, czyli TestingCup. Każdego roku aplikacja stanowi wyzwanie dla setek testerów. Z roku na rok mamy do czynienia z inną odsłoną, a także z inną specyfikacją.

Dlaczego Mr Buggy to przyjaciel każdego początkującego testera?

Aplikacja jest przygotowywana na każde zawody i celowo zawiera błędy. Za każdym razem mamy do czynienia z inną wersją, a także z dokumentacją w innej formie. To właśnie dzięki tej różnorodności Mr Buggy jest przyjacielem każdej początkującej osoby. Stwarza to spore możliwości do ćwiczeń i nauki.

Polecam wykonanie kilku zadań w celu doskonalenia testerskiego warsztatu.

To, co według mnie jest warte podkreślenia, to niezwykły wkład organizatorów w testing community. Po zawodach udostępniają aplikację, z którą mierzą się zawodnicy. Publikowana jest także lista znanych błędów oraz najlepsze raporty czy plany testów. Może być to niezwykle ważne dla osób, które chcą zacząć swoją przygodę z testowaniem, bo pozwala na sprawdzenie własnych wyników.

Według mnie jest to świetny poligon do ćwiczeń, o czym będzie mowa poniżej. Uważam wręcz, że przejście przez dotychczasowe oblicza Mr Buggiego, daje spore możliwości zapoznania się z chociaż częścią testerskiego rzemiosła. Oczywiście codzienna praca w tym zawodzie jest dużo bardziej złożona i pełna innych obowiązków. Te ćwiczenia mogą być doskonałym startem kariery testera.

Czego nauczysz się pracując z Mr Buggym?

Przede wszystkim masz możliwość pracy z dokumentacją. Trzeba zaznaczyć, że za każdym razem specyfikacja jest przygotowana w innej formie, co daje jeszcze szersze pole do działania i nauki. Kolejną rzeczą jest oczywiście samo testowanie. Masz do dyspozycji różne wersje specjalnie przygotowanej aplikacji, która wykorzystywana była podczas zawodów. Oznacza to, że zawierają one błędy, czasami łatwe, a czasami trudniejsze do wykrycia. Błędy są jawne, co pozwala sprawdzić swoje umiejętności i porównać wyniki z najlepszymi zgłoszeniami.

Następnie na bazie przeprowadzonych testów można przygotować raport. Tu ponownie masz możliwość porównania Twojego dokumentu z udostępnionymi, najlepiej ocenionymi raportami.

Jeśli dopiero zaczynasz lub myślisz o rozpoczęciu swojej przygody z testowaniem, to namawiam Cię do wykonania kilku ćwiczeń z Mr Buggym. Będą one podobne do tego, z czym mierzą się zawodnicy podczas mistrzostw. W trakcie zawodów uczestnicy mają zwykle dwa główne zadania. Pierwsze to przeprowadzenie testów oraz zaraportowanie znalezionych defektów. Drugie to przygotowanie dokumentacji testowej (raport z testów lub plan testów).

Ćwiczenia

Chciałbym zachęcić Cię do nieco innego podejścia. W ramach ćwiczeń możesz pobrać dowolną wersję Mr Buggiego oraz wykonać trzy poniższe zadania. Dzięki temu pokryjesz sporą część codziennych zadań testera, a przez to nauczysz się więcej na temat samego testowania.

1. Przygotuj przypadki testowe dla wybranej funkcjonalności (jednej lub kilku).

2. Przeprowadź testy i zaraportuj znalezione defekty — możesz tu wykorzystać przygotowane przypadki testowe.

3. Przygotuj raport z testów.

W dalszej części opisuję poszczególne wersje Mr Buggiego. To pomoże Ci dobrać odpowiedni program do Twoich umiejętności. Zanim przejdę do charakterystyki kolejnych wersji aplikacji, w kilku słowach opiszę zadania do wykonania.

Praca z dokumentacją

Jeśli w projekcie istnieje dokumentacja, jej przeanalizowanie to jedno z podstawowych zadań testera. Możesz to sobie przećwiczyć, korzystając ze specyfikacji przygotowanych na zawody TestingCup. Podczas czytania dokumentów ważne jest zwracanie uwagi na szczegóły, nieścisłości, niedopowiedzenia. Tak jest podczas pracy w projekcie. Nie inaczej jest z Mr Buggym.

Przez pracę ze specyfikacją do aplikacji Mr Buggy masz okazję nauczyć się przede wszystkim definiowania właściwego zakresu testów. Zwróć uwagę na to, co powinno być testowane, a do czego błędów nie należy zgłaszać. To pozwala skupić się na tym, co jest najważniejsze. Nie będziesz też tracić czasu na sprawdzanie tego, co nie znajduje się na liście.

Przygotowanie przypadków testowych

Analizując dokumentację, możesz wykonać ćwiczenie polegające na przygotowaniu przypadków testowych. Zadanie warto zacząć od przygotowania sobie szablonu przypadku testowego, który później będziesz wypełniać danymi. Forma i narzędzie zależą od Ciebie.

W celu wykonania zadania, wybierz wersję, od której chcesz zacząć. Następnie zdecyduj się na jedną lub kilka funkcjonalności/ekranów i przygotuj do nich przypadki testowe. Do tego ćwiczenia nie znajdziesz rozwiązania na oficjalnej stronie Mr Buggy, ale moim zdaniem warto przez nie przejść. Rezultat tego ćwiczenia możesz później wykorzystać w procesie rekrutacji.

Testowanie oraz raportowanie błędów

Teraz czas na przeprowadzenie testów. Możesz to zrobić na podstawie przygotowanych przypadków testowych lub na podstawie dostarczonej specyfikacji.

Przed rozpoczęciem testowania zachęcam do przygotowania szablonu zgłoszenia defektu, który później będziesz wypełniać danymi. To pozwoli na bardziej efektywne ich zgłaszanie. Możesz skorzystać z szablonu z poprzedniego rozdziału lub przygotować własny.

W kolejnym kroku wybierz wersję do testów. Poniższe informacje mogą pomóc w dokonaniu odpowiedniego wyboru. Osoby początkujące mogą zacząć według mnie od Mr Buggy 3 oraz 6. Dobrym ćwiczeniem na początek mogą być także retesty defektów w wersji 4.

Jeśli wykonałeś ćwiczenie z dokumentacją, to zapewne już wiesz, z którą wersją rozprawisz się w pierwszej kolejności. Zachęcam do zmierzenia się z każdą z tych aplikacji. Zaraportowane błędy możesz porównać z udostępnionymi przez ekipę TestingCupa i zobaczyć jak Ci poszło.

Przygotowanie raportu

Ostatnią rzeczą, o której wspominałem w sekcji z ćwiczeniami, jest przygotowanie raportu z testów. Zakładam, że wykonałeś wszystkie poprzednie zadania i teraz czas na pewne podsumowanie wykonanej pracy w postaci raportu końcowego. Poniżej wymienię elementy, które według mnie powinny znaleźć się w takim dokumencie.

— Cel testów — krótka informacja na temat testowanej aplikacji.

— Opis środowiska, w jakim testy zostały przeprowadzone — informacje na temat wersji systemu operacyjnego, przeglądarki itp.