Jak wygląda proces testowy? Część 1

Proces testowy – to jest to o czym chciałabym dzisiaj Wam opowiedzieć. W poprzednich artykułach opisywałam niektóre elementy tego procesu. Teraz postaram się dodać jeszcze parę informacji i zebrać wszystko w całość.

Aby testowanie dawało dobre rezultaty, musi być zaplanowane i usystematyzowane. Można powiedzieć, że takie ułożenie testowania to proces testowy. Nie ma jednak jednego jedynego, szablonowego procesu testowego. W praktyce, to co jednych projektach się sprawdza, w innych zupełnie nie będzie miało prawa bytu. Można jednak spróbować wydzielić pewne czynności które będą wspólne.

Podstawowy proces testowy

Zwykle podstawowy proces testowy opisywany jest jako zestaw czynności takich jak:

  • planowanie
  • kontrola
  • analiza
  • projektowanie
  • implementacja
  • wykonanie
  • ocena i raportowanie
  • zamykanie czynności testowych

Wprawdzie wypisałam te czynności jedno pod drugim ale nie znaczy to, że one muszą odbywać się jedna po drugiej (chociaż czasem narzuca to metodologia w której pracujemy, lub też rodzaj testów które aktualnie wykonujemy wykonujemy).

Planowanie

Proces testowy zaczynamy od planowania. Z planowaniem testów na początku projektu jest trochę jak z zakupami. Musimy pomyśleć – co będzie nam potrzebne, co musimy wcześniej zrobić lub mieć by móc iść na zakupy, co mamy kupić itp. To samo dotyczy planowania testów. Przed rozpoczęciem testowania musimy przecież wiedzieć co jest nam potrzebne (np. jakie narzędzia) i jakie czynności powinniśmy wykonać. Powinniśmy się również na tym etapie zastanowić jak będziemy mierzyć nasze testy (wspomniane w poprzednich artykułach metryki).

To jest ten moment kiedy decydujemy jakie poziomy, typy i techniki testów będą wykorzystywane oraz jakie chcemy osiągnąć cele na poszczególnych etapach testowania. Planować możemy a nawet powinniśmy także w trakcie wprowadzania zmian, podejście do testów może w trakcie trwania projektu ulec zmianie. Być może jakaś funkcjonalność będzie wymagała zupełnie innego nakładu pracy niż początkowo nam się wydawało i okaże się, że ponownie trzeba zaplanować proces testowy.

Oczywiście zespół planujący bądź osoba planująca nie może zapomnieć o wzięciu pod uwagę ograniczeń, ryzyk, wymagań oraz obowiązków – specyficznych dla projektów, technologii itp. Jak i dodatkowego czasu na wszystkie elementy około testowe, o których często się zapomina tj. dokumentacja, konfiguracja środowisk itp.

Faza planowania ma przygotować produkt do fazy testowej, tak by mieć pewność, że to co zostanie dostarczone będzie satysfakcjonujące i spełniające wymagania klienta.

No dobrze a co to oznacza w praktyce?

Praktycznym przełożeniem teorii na praktykę jest spisanie test planu. Test plan pomaga nam spiąć całą wiedzę o testach w całość.

W test planie możemy zawrzeć informacje takie jak:

  • cel testów i ich ograniczenia
  • elementy testowe i ich wersje
  • części aplikacji które zostaną poddane testom, odniesienia do wymagań i / lub specyfikacji
  • części aplikacji które nie zostaną poddane testom (wraz z podaniem powodu dlaczego nie)
  • podejście do testów (np. testujemy tylko eksploracyjnie), typy testów, metody testowania (np. czy manualnie czy automatycznie) itp
  • kryteria akceptacji / odrzucenia – określenie kryteriów, które będą używane w celu ustalenia czy aplikacja przeszła pomyślnie test czy też nie
  • rzeczy które są dostarczane razem z testami np. plan testów (sam dokument), przypadki testowe, skrypty testowe, dzienniki błędów, raport z testów
  • środowisko testowe – opisanie środowiska testowego, jego parametrów itp
  • harmonogram – określ ramy czasowe, najważniejsze milestony, warto dodać link do szczegółowego harmonogramu prac jeśli jest taki dostępne
  • skład teamu – można opisać skład zespołu, wymienić obowiązki każdego zespołu / roli / osoby.
  • zagrożenia i ryzyka – wypunktować zidentyfikowane zagrożenia, opisać plan niwelujący dane ryzyko i plan awaryjny w razie jego wystąpienia
  • założenia i zależności – wymienienie założenia, które zostały poczynione podczas przygotowania dokumentu, wymienić zależności (czy od czegoś zależy projekt np. współpraca z innymi dostawcami)
  • osoby zatwierdzające plan

Taki plan nie powinien być pisany raz na projekt. Powinien być zawsze aktualizowany w ramach zmieniających się warunkach projektowych. Pamiętaj – przestarzały i nieużywany dokument nikomu nie przyniesie korzyści.

Kontrola

Może was zdziwi, że opisuję kontrolę jako drugi punkt a nie gdzieś na końcu – kontrola odbywa się przez cały czas. Pod pojęciem kontrola – kryją się dwa kolejne. Monitoring i nadzór.

Monitorowanie

Monitorowanie to tak naprawdę sprawdzanie czy idziemy w dobrym kierunku, czy wszystko idzie zgodnie z zakładanym planem. Przykładem który przychodzi mi do głowy jest scrum. Mamy boarda na którym mamy zaplanowaną pracę na sprint, osoba odpowiedzialna monitoruje czyli sprawdza czy wszystkie taski idą zgodnie z planem. Czy nie ma opóźnień i czy wszystkie taski zostaną dostarczone na czas – czyli na koniec sprintu a w dłuższej perspektywie czy zespół dostarczy produkt na czas,

Dobrze, a w jaki sposób możemy monitorować projekt? Możemy użyć metryk takich jak:

  • stosunek ilości zadań zakończonych do zadań zaplanowanych w danym okresie czasu np. w sprincie
  • stopień pokrycia np. kodu testami
  • liczba pozytywnie zakończonych przypadków testowych
  • liczba zgłoszonych błędów czy liczba naprawionych błędów

Tak naprawdę tych metryk jest sporo, dlatego tylko wspominam w przyszłości być może powstanie o tym osobny artykuł.

Raportowanie

Do monitorowania projektu zaliczamy też raportowanie na przykład raportowanie testów. Po w trakcie jak i po zakończonych testach dobrze jest stworzyć raport z testów. Poziom jego sformalizowania i forma często jest zależna od projektu. Nie mniej warto wiedzieć co powinno się znaleźć w takim raporcie:

  • cel stworzenia dokumentu, kto jest adresatem
  • krótki opis aplikacji, systemu, produktu
  • zakres testów czyli co podlegało testom a co nie
  • opis środowiska testowego – typy testów jakie zostały przeprowadzone np. smoke testy, testy eksploracyjne, testy wydajnościowe, testy regresji
  • metryki np. pokrycie kodu testami, wyniki testów, ilość wykonanych test casów z rozpisaniem jakie były wyniki, ilość zgłoszonych błędów
  • jakie i czy zostały wszystkie kryteria wejściowe spełnione
    opis krytycznych problemów i sposobów radzenia sobie z nimi – takie lessons learned
  • podsumowanie
  • rekomendacje

Taki raport tak jak wspomniałam może być dowolnie modyfikowany, najważniejsze jest by odbiorca uzyskał jasną i czytelną informację o zakończonych testach.

Nadzór

A co jeśli okazuje się, że coś jest nie tak? Gdy widzimy, że projekt nie idzie zgodnie z planem i mamy opóźnienia? Oczywiście należy działać tak by wszystko ponownie szło zgodnie (czasem z nowym) planem. I tutaj mamy do czynienia z nadzorem.

Wyobraźmy sobie następującą sytuację – raport wykazał iż w tej iteracji zgłoszono znacznie więcej błędów niż zwykle, co wtedy? Wtedy na przykład należy przeprowadzić analizę źródła problemu a w następnej kolejności zastanowić się nad kolejnymi krokami – np czy konieczne jest przedłużenie fazy testowej czy też konieczna będzie redukcja ilości zadań zaplanowanych na następny sprint po to by programiści zdążyli naprawić błędy.

Porównując monitoring i nadzór możemy stwierdzić monitoring to taka obserwacja, a nadzór już wiąże się z podejmowaniem konkretnych decyzji i działań.

Analiza

Podczas fazy analizy określamy co powinno być przetestowane, na tym etapie równie definiujemy warunki testowe. Brzmi enigmatycznie ale w tej fazie nasze założenia nabierają tak naprawdę realnych kształtów.

W pierwszym kroku należy określić przedmiot testów i elementy testowe, w kolejnym kroku należy dokonać przeglądu podstawy testów (które będą różne w zależności od poziomu testów), celów testowania czy też dokonać analizy ryzyka. Dzięki czemu uzyskamy coś na kształt wskaźnika, miarę osiągniętego sukcesu, a zarazem będzie to pewna część kryteriów wyjściowych.

Ok, wydaje mi się że nadal brzmi to dosyć mglisto. To przytoczę przykłady poziomów testów i odpowiadającym im podstawy testów.

Proces testowy - poziomy testów i podstawa testów Na podstawie Hass M.A. Guide to Advanced Software Testing, Artech House, Inc. Norwood 2008

To jeszcze raz kilka słów o test case’ach

Jak wiecie już z mojego artykułu o przypadkach testowych – mogą one być tworzone na różnych poziomach ogólności. Im wyższy poziom tym więcej będziemy mieć warunków testowych. Ważne jednak jest by były powiązane z podstawą testów. Dzięki temu będziemy mogli mierzyć nasze metryki np. stopień pokrycia kodu.

Każdy przypadek testowy tak naprawdę możemy przełożyć na konkretny element np. linię kodu, funkcję, moduł itd który pokrywamy konkretnym testem. Rozpatrując każdy przypadek możemy rozpatrzyć możliwość wystąpienia jakiegoś ryzyka, które potem możemy odnieść do wymagania. Gdy mamy przypadek testowy – możemy go odnieść nawet do kilku wymagań.

Na przykład mając 3 metody składające się na jedno wymaganie np.

  • getStatus(),
  • setStatus(),
  • removeStatus()

Nasze wymaganie zostanie pokryte w 100% tylko gdy wszystkie 3 metody zostaną przetestowane.

Podsumowując, w ramach procesu analizy analizy, analizujemy wymagania, ryzyka, specyfikację, kod by dowiedzieć się co chcemy testować..Kolejnym krokiem jest projektowanie testów.

Projektowanie testów

Dzięki analizie testów wiemy już “co testować” czyli zidentyfikowaliśmy obiekty testów. Projektowanie testów odpowie nam na pytanie “jak” testować.

Czynności jakie powinniśmy wykonać w ramach projektowania testów:

  • wybrać poziom szczegółowości test casów dla konkretnych testowanych obszarów
  • wybrać techniki projektowania (o tym też pisałam w poprzednim artykule)
  • tworzenie przypadków testowych

Ogólne przypadki testowe mogą być pisane na przykład gdy nie znamy jeszcze dokładnie wymagań, lub są one mało szczegółowe. Przy wykonywaniem tego rodzaju test casów tester musi odznaczać się doświadczeniem, znajomością technik czy samej aplikacji. Przez to, że test casy są ogólne – jesteśmy w stanie łatwiej uzyskać większy stopień pokrycia. To podejście sprawdza się w projektach z mniejszym naciskiem na dokumentację.

Bardziej szczegółowe przypadki testowe są pisane często w “rygorystycznych” projektach, gdzie wszystko musi być skrzętnie dokumentowane lub też w projektach z mniej doświadczonymi testerami w zespole. Często ułatwiają transfer wiedzy projektowej. Bardziej ogólne przypadki testowe,zwykle są tworzone na początku a w ramach rozwoju projektu, przypadki są doprecyzowywane i rozwijane.

Przypadki testowe powinny być: powtarzalne, niezależne, weryfikowalne

Gdy mamy stworzone przypadki testowe, koniecznym jest nadawanie im priorytetów oraz przypisać do danego poziomu testów. Ostatnim elementem projektowania testów jest zaplanowanie środowiska testowego oraz niezbędnej architektury i narzędzi.

Kolejną fazą jest implementacja i wykonanie testów ale o tym i o reszcie procesu – napiszę w następnym artykule

Podsumowanie

A teraz chciałabym krótko podsumować to o czym dzisiaj czytaliście. Chyba trochę pod skórą czujecie, że wszystkie te procesy sie przenikają ze sobą i są ze sobą ściśle powiązane.

Możemy napisać test plan ale bez pozostałych elementów procesu nie będzie on wiele zawierał ponieważ nie będzie podstawowych informacji. Bez monitoringu nie będzie wiadomości o stanie projektu, ale aby powstał raport musimy wiedzieć co i jak testować. Nie da się opisać uniwersalnego procesu testowego.

Mamy jasno określone wskazówki jak on powinien wyglądać – ale tak jak każda aplikacja jest inna, każdy zespół deweloperski jest inny, tak każdy proces testowy jest inny. To co sprawdzi się w zespole A nie jest powiedziane, że sprawdzi się w zespole B. I to co ważne – procesy są dla nas, a nie my dla procesów. Procesy mają nam ułatwiać życie a nie je utrudniać. O czym często zapominamy projektując proces testowy w naszych projektach.