Pasja Testowania - ebook

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=mc²”, 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, SIT, 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.

Story point — jednostka estymacji user story. Odzwierciedla stopień złożoności danego wymagania. Często korzysta się z liczb z ciągu Fibonacciego: 0, 1, 2, 3, 5, 8, 13, 20 itd. Poszczególne user story porównuje się ze sobą, by określić stopień złożoności. W takim podejściu wymaganie wyestymowane na 2 story pointy jest uważane za dwukrotnie bardziej skomplikowane niż to wyestymowane na 1 story point. Bardzo często można też spotkać podejście, by dzielić user story na mniejsze, które jesteśmy w stanie ocenić dokładniej. Kandydatami do takiego podziału są przeważnie te, które zostały wycenione na co najmniej 13 story pointów. To oczywiście może się różnić w zależności od przyjętego podejścia.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 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.

— Podejście testowe — typy testów, które były planowane do wykonania i te, które były wyłączone z testowania.

— Zakres testów — lista funkcjonalności, które zostały przetestowane, lista tych, które nie zostały sprawdzone oraz funkcjonalności wyłączonych z testowania.