Dzisiaj chciałabym kontynuować swój poprzedni post o procesie testowym, w którym dowiedzieliście się jak wygląda planowanie, kontrola, analiza i projektowanie testów. W tym artykule dowiecie się jak wyglądają kolejne etapy procesu testowego takie jak – implementacja, wykonanie, ocena i raportowanie i zamykanie czynności testowych. Na koniec postaram się wszystko zebrać w całość i krótko podsumować. No to zaczynajmy.
Ostatnio skończyliśmy opisywać nasz proces testowy w miejscu, gdzie mieliśmy stworzone przypadki testowe, nadaliśmy im priorytety i określiliśmy poziomy testów. Kolejnym krokiem jest Implementacja testów.
Implementacja
Zwykle, większość osób myśląc o testowaniu i o tym co tester robi na co dzień, myśli o tych czynnościach, które wykonywane są w fazie implementacji i wykonywania testów. Czym zatem jest implementacja testów? To jest ten moment, kiedy, nasze założenia wykonane we wcześniejszych fazach stają się faktem, realizacją.
Na tym etapie zaczynamy implementować stworzone przypadki testowe. Tak naprawdę w tym momencie możemy ten nasz przypadek testowy przełożyć na kod testu wykonującego nasz przypadek testowy bądź cały scenariusz testowy. Możemy jeszcze dokończyć ich piorytetyzację oraz określić jakie dane testowe będą nam potrzebne podczas ich wykonywania.
No właśnie dane testowe – już o nich wspominałam wcześniej w jednym z poprzednich artykułów. W kontekście tej fazy testów najczęściej mówimy o:
– implementacji danych w konkretnych przypadkach testowych np. poprawne dane użytkownika w przypadku testowym związanym z logowaniem z użyciem prawidłowych danych logowania
– implementacja generatorów danych – gdy nasz projekt wymaga dużej ilości danych, o określonej strukturze a na przykład dostępne generatory danych nie spełniają naszych oczekiwań i potrzeb.
Mówiąc o implementacji musimy jeszcze wziąć pod uwagę nasze środowiska testowe:
– skonfigurować sprzęt, który będziemy używać np. serwery, czytniki, jeśli takowe będą potrzebne itp.
– zainstalować i skonfigurować niezbędne oprogramowanie np. system operacyjny, bazy danych, środowisko uruchomieniowe
– tworzenie atrap potrzebnych do wykonania testów, które na przykład używają modułu, który jeszcze nie został stworzony.
Czasami mówi się o fazie implementacji i wykonania testów, bo ta pierwsza faza zwykle jest ściśle powiązana z tą drugą. Zatem gdy mamy już nasze przypadki, dane i przygotowane środowiska testowe możemy zacząć myśleć o wykonaniu testów.
Wykonanie testów
Wykonywanie testów jest ściśle związane z planem, który stworzyliśmy wcześniej. Czym właściwie jest wykonanie testu? To jest proces wykonany na module lub systemie, dzięki któremu otrzymujemy wynik. A tak bardziej obrazowo – gdy wykonujemy przypadek testowy – otrzymamy wynik, na podstawie którego stwierdzimy, że test przeszedł – jeśli rezultat był taki jak się spodziewaliśmy lub też nie – jeśli efekt jest inny od spodziewanego – czyli prawdopodobnie mamy do czynienia z jakimś błędem w kodzie. No właśnie – w kodzie, czy aby na pewno?
Osoby piszące test, również mogą się mylić. Na przykład, jeśli w wyniku pomyłki osoby tworzącej test spodziewamy się, że po wpisaniu poprawnych danych logowania i zatwierdzeniu ich, użytkownik nie zostanie zalogowany, w wyniku testu uzyskamy logowanie zakończone sukcesem uzyskamy wynik testu niezgodny z oczekiwaniami. W tym przypadku to nie jest usterka w programie, ale w teście.
Jaki jest z tego wniosek? Po otrzymaniu negatywnego wyniku testu przed zgłoszeniem go – powinniśmy upewnić się, że otrzymany wynik faktycznie wynika z błędu w kodzie programu a nie z błędnego testu.
Oczywistą rzeczą jest chyba to, że wyniki wykonanych testów muszą być logowane np. zapisywane w postaci raportu. Dzięki czemu możemy kontrolować wyniki i weryfikować, czy są one zgodne z postawionymi oczekiwaniami. To również może stanowić pewne zabezpieczenie na wypadek opóźnienia w projekcie. Mamy jasną informację dla klienta – wystąpiło opóźnienie, ponieważ wtedy i wtedy mieliśmy problemy, które należało rozwiązać. Takie dzienniki testów też powinny zawierać informacje jasno identyfikującą wersję testowanego oprogramowania oraz środowisko testowe.
W tej fazie jeszcze możemy powtarzać czynności testowe np. jeśli stwierdzimy rozbieżności – by upewnić się, że faktycznie to błąd występuje, albo ponownie wykonać test by potwierdzić naprawę błędu, ponownie uruchomić testy po zmianie w testach itp.
Oczywiście założony plan uwzględnia pewne odstępstwa tak by tester mógł przeprowadzić jakieś dodatkowe testy, jeśli wymaga tego sytuacja albo coś szczególnie go zaintryguje.
Ocena i raportowanie
Jedną z ostatnich faz jest ocena i raportowanie – tak naprawdę polega na określeniu czy uzyskane wyniki są zgodne z celami testowania. Ocena powinna być wykonana dla każdego poziomu testów.
Ocena wyników tworzona jest na podstawie monitorowania postępów w testach oraz spełnieniu określonych kryteriów, które zostały zdefiniowane wcześniej. Co to oznacza w praktyce? Moglibyśmy przyjąć, za kryterium wyjścia takie warunki:
– wszystkie znalezione w danej fazie błędy muszą zostać naprawione
– wszystkie błędy znalezione w danej fazie, oznaczone jako blocker i critical muszą zostać naprawione – stopień pokrycia kodu testami musi być większy niż 80%
I tym podobne.
Definiując kryterium wyjścia należy być ostrożnym i brać pod uwagę czynniki poboczne np. długość trwania projektu. Poziom i kategoryczność kryteriów mogą być różna. Część kryteriów wiadomo jest „zero-jedynkowa”, bo nie można wypuścić na produkcję błędów z niedziałającą kluczową funkcjonalnością, ale czasem w sytuacji, gdy spełnienie kryteriów, w określonej sytuacji jest trudne – możliwe jest redefiniowanie kryteriów wyjścia.
Dlaczego tak? W trakcie procesu testowego często nasze założenia są weryfikowane przez rzeczywistość na przykład – zespół nie jest tak wydajny jak nam się wydawało, czy ma jakieś braki w wiedzy, których nie byliśmy świadomi i cały proces się wydłuża przez co nie może poświęcić tyle czasu na np. pisanie testów automatycznych przez co nie jesteśmy w stanie spełnić warunku o minimalnym procentowym pokryciu testami automatycznymi. Nie mniej – to jest broń obusieczna. Obniżenie kryteriów może wpłynąć na jakość produktu. Nie bez powodu mówi się często – albo coś się robi szybko albo dobrze.
Tak naprawdę, gdy mamy już wyniki naszych testów, często generowane automatycznie jesteśmy w stanie stworzyć raport na potrzeby klienta czy też osób wyższego szczebla o stanie projektu. Treść, forma, poziom ogólności zależy od projektu, od samej osoby zainteresowanej. Osoby mające wpływ na kierunek projektu zwykle chcą mieć bardziej szczegółowy raport, wraz z metrykami, z informacjami o znalezionych błędach itp. a czasem wystarczy krótki raport dla klienta czy idziemy zgodnie z planem.
Czynności zamykające testowanie
Ostatnią fazą są czynności zamykające testowanie. Co kryje się pod tą nazwą? Ja bym powiedziała krótko – podsumowanie. To jest po prostu podsumowanie tego co się działo w ramach procesu. W ramach tego osoba odpowiedzialna ma do wykonania następujące zadania:
– sprawdzić, czy wszystko zostało dostarczone zgodnie z planem i dokumentacją
– zarządzanie błędami, czyli zamykanie notek, tworzenie nowych, edycja istniejących, jeśli jest taka potrzeba
– utrzymywanie dokumentacji
– prace niezbędne do utrzymania środowiska testowego i ponownego użycia w przyszłości
– spotkanie retrospektywy
– zachowanie artefaktów procesu testowego
Większość z tych rzeczy wydaje się oczywista, jednakże w natłoku pracy, często pod presją czasu może zdarzyć się, że zapominamy o rzeczach oczywistych. Taka weryfikacja pozwala nam upewnić się, że niczego nie przeoczyliśmy.
A jak do tego ma się praktyka?
Pierwszym etapem jest planowanie, więc zacznijmy od test planu. W projektach Agile w porównaniu do modelu waterfall, test plan jest napisany, aktualizowany dla każdego releasu. Test plan zawiera typy testów wykonanych w iteracji, wymogi dotyczące danych testowych, infrastruktury, środowiska testowego. Przykładowy test plan zawiera:
– zakres testów
– funkcjonalności, które zostaną przetestowane
– poziomy i typy testów
– kryteria akceptacji
– przemyślaną architekturę
– zasoby
– ryzyka
– założenia i zależności
Zwykle proces testowania przebiega w 4 fazach:
Sprint 0, podczas tego sprintu, przeprowadzane są taski inicjujące obejmujące na przykład instalację narzędzi testowych, przygotowanie środowisk testowych, rezerwację zasobów. W tej iteracji możemy też uzgodnić założenia biznesowe, warunki brzegowe, zakres projektu, określić kluczowe wymagania i przypadki użycia, przedstawić zarys architektury, zidentyfikować ryzyka, oszacować wstępne koszty itp. To taka faza pozwalająca rozkręcić projekt. Przygotować się do niego, czyli przygotować plan, środowiska, przygotować dane testowe itp. itd.
Sprinty – Iteracje, to na tym etapie odbywa się większość testów. Ta faza jest zbiorem iteracji w których powstaje system, produkt itp. Drugą fazą są sprinty. Większość testów jest wykonywana w tej fazie. Ta faza to zestaw iteracji których efektem ma być przyrost w tworzonym rozwiązaniu. Testy podczas iteracji możemy podzielić na dwa rodzaje – testy potwierdzające i testy oparte na doświadczeniu. Testy potwierdzające koncentrują się na sprawdzeniu czy system spełnia założenia, drugi rodzaj testów pozwala wykryć problemy które z jakiegoś powodu mogły zostać pominięte lub zignorowane. Również testy potwierdzające możemy podzielić na testy wykonywane podczas developmentu jak i testy akceptacyjne. Oba z nich zwykle są (powinny być) zautomatyzowane, tak by móc wykonywać regularne testy regresji przez cały cykl tworzenia oprogramowania.
Celem tworzenia oprogramowania jest doprowadzenie naszego produktu do takiego stanu, że wiemy, że może być bez obaw używany przez użytkowników – czyli wypuszczenie produktu „live”. Czynności zawarte w tej fazie obejmują przeszklenie użytkowników, wprowadzenie na rynek produktu, tworzenie kopii zapasowych i przywracanie w razie potrzeby, dopracowywanie dokumentacji itp.
Ostateczna faza testów obejmuje pełne testy systemu i testy akceptacyjne. Na tym etapie testy powinny być już znacznie bardziej rygorystyczne by mieć pewność, że wszystko działa jak należy zanim aplikacja trafi na produkcję. Ostatnią fazą jest wersja produkcyjna
Ciekawym zobrazowaniem podejścia do testów jest kwadrat Agile.
Kwadrant testowania Agile
Poniższa grafika przedstawia kwadrat testowania Agile. Kwadrant dzieli cały proces na 4 części i pomaga zrozumieć jak przeprowadzone mogą być testy w Agile.
Część 01 – w tej części najbardziej skupiamy się na jakości kodu. Obejmuje testy jednostkowe i testy komponentów.
Część 02 – ta część zawiera przypadki testowe które są skierowane na spełnienie oczekiwań biznesowych jak i wspierających team. Ta część skupiona jest na wymaganiach, testy obejmują scenariusze, przepływy, testy prototypów, regresji czy testowaniem w parach.
Część 03 – przypadki które w tej części stosujemy zwykle pozwalają nam na zbudowanie zaufania do produktu. Zwykle są to testy eksploracyjne, testy akceptacyjne oraz testy użyteczności.
Część 04 – tutaj zwykle skupiamy się na aspektach niefunkcjonalnych takich jak na przykład wydajność, bezpieczeństwo, stabilność.
Ten diagram pokazuje jak wiele obszarów ma do obsłużenia osoby odpowiedzialne za jakość produktu.
Podsumowanie
Tak naprawdę metodologia stosowana w projekcie nie wyklucza żadnego z powyższych kroków. W rzeczywistości w projektach wykorzystujących Agile zwykle dosyć dobrze są zdefiniowane zasady testowania i dokumentacji. Testowanie jest podstawową i kluczową częścią każdego procesu tworzenia oprogramowania.
Zasada jest prosta, proces testowy należy zacząć tak szybko jak to jest możliwe. Często wymaga to dużego zaangażowania ze strony klienta. Połową sukcesu jest odpowiednie zaplanowanie testów i przygotowanie scenariuszy testowych i danych testowych. Kod powinien być wystarczająco stabilny by móc przejść do dalszych etapów testowania. Można przeprowadzić obszerne testy regresji, aby upewnić się, że wszystkie błędy zostały naprawione i przetestowane. Głównie komunikacja między członkami zespołu jest kluczem do sukcesu.
Dzięki odpowiedniemu zaplanowaniu testów, możemy czerpać korzyści z dostarczania wysokiej jakości produktu za każdym razem. I pamiętajcie – procesy są dla nas – nie my do procesów. Każdy projekt jest inny, w jednym projekcie proces będzie wyglądał w ten sposób, w innych ulegnie on modyfikacjom.
