Co zrobić, aby usprawnić proces testowania i prowadzenie projektu? Czy dobór testów i odpowiednie planowanie wystarczy? O tym przeczytasz w artykule.

 

Każdy z nas chce jak najlepiej wykonywać swoją pracę i oddawać produkt o najwyższej jakości. Niestety jak wiemy, nie ma złotego środka, który można zastosować w przypadku każdego projektu i takiego, który będzie gwarancją, że oddany projekt spełni kryteria najwyższej jakości.

Dlaczego?

Przyczyna jest prosta: projekty są różne i często rządzą się swoimi prawami. Metodologie prowadzenia tych projektów też nie są identyczne. Często zdarza się, że dany projekt, który z założenia jest prowadzony w metodologii scrum jest modyfikowany w taki sposób, by odpowiadał projektowi czy też zespołowi. I wreszcie najistotniejsza kwestia dla działu kontroli jakości: wielkość zespołu oraz jego doświadczenie są zróżnicowane.

Co zatem możemy zrobić, aby usprawnić proces testowania i samo prowadzenie projektu? Możemy odpowiednio zaplanować testy! Tylko jak to zrobić….

Na początek zaprezentuję trochę teorii a następnie przejdę do przykładów. Możliwe, że dla niektórych nie będzie to nowa wiedza, lecz warto uporządkować kilka spraw. Do głównych czynników, od których należy zacząć planowanie testów zaliczamy:

  1. Złożoność projektu – warto zastanowić się z jak wielu elementów złożony jest system, ile jest poziomów integracji. I pewnie niektórzy z Was mają teraz przed oczami poziomy testów. Słusznie.
  2. Poziom ryzyka projektu – inaczej podejdziemy do tematu aplikacji webowej służącej do zamawiania kuriera, a inaczej do systemu przechowywania wrażliwych danych. W tym punkcie chodzi o to, jak wysokim ryzykiem obarczony jest projekt i jak dotkliwe mogą być konsekwencje w razie niepowodzenia. W przypadku systemów medycznych błąd może oznaczać nawet utratę życia przez pacjenta.
  3. Dostępne zasoby – zasoby rozumiem jako dostępny zespół, jego doświadczenie oraz możliwość korzystania z narzędzi np. testy automatyczne lub wydajnościowe.

Przechodzimy do działania!

Faza 1: Faza planowania

Jest ona niezwykle ważna, ponieważ błędy popełnione w tej części mają wpływ na każdą pozostałą fazę i są kosztowne w naprawie, zupełnie jak w przypadku wykrytego błędu – im szybciej wykryty, tym taniej można go naprawić. W zależności od danej sytuacji planowanie może nastąpić w gronie:

  • Cały zespół testerski wraz z zaproszonymi ekspertami np. Analitykami biznesowymi;
  • Cały zespół testerski;
  • Wybrana część zespołu;
  • Jeden tester;

Najlepszym rozwiązaniem jest wprowadzenie spotkań planujących we wszystkich czterech wariantach. Faza ta to nie tylko czas zaplanowania testów i dobrania odpowiednich metod i przypadków. To także czas, w którym już realnie przystępujemy do testów wymagań a nie aplikacji.

Dlaczego tak ważna jest ta faza?

W tym momencie można posłużyć się metaforą. Jeśli źle rozplanujemy układ domu, nie będzie on funkcjonalny lub też pokoje nie będą ustawne. Owszem można w nim mieszkać i codziennie irytować się danym stanem rzeczy, ale nie to było celem całego przedsięwzięcia pt. Zaprojektujmy dom marzeń. Przykład bardziej z naszego ‘podwórka’. Planujemy testy tylko funkcjonalne, natomiast absolutnie nie zwracamy uwagi na użyteczność i wydajność, które mogą okazać się kluczowe dla zamawiającego dany produkt. Wykonaliśmy bardzo dużo testów, byliśmy zadowoleni z efektów a finalnie okazuje się, że źle przygotowaliśmy się do naszej pracy.

Na tym etapie na początku pozyskujemy wiedzę głównie od analityków biznesowych, menedżerów projektu, starszych testerów, architektów systemowych. Nie szukamy odpowiedzi na pytanie co mamy przetestować, lecz:

Co jest ważne dla projektu i jak z punktu widzenia biznesu powinien działać system?

Za kwestie doboru odpowiadamy my, ale nie zrobimy tego odpowiednio bez wiedzy, którą posiadają pozostali członkowie zespołu. Jeśli to możliwe warto dowiedzieć się jaki jest klient, na co zwraca uwagę, co jest dla niego ważne. Poza dostarczeniem produktu o najwyższej jakości zależy nam, aby odbiorca dostał to czego od naszej firmy oczekiwał.

Na co warto zwrócić uwagę podczas doboru testów:

  • Dla kogo jest projekt – na co zwraca uwagę klient;
  • Które moduły są kluczowe;
  • Na jakich środowiskach powinny odbyć się testy (np. Przy webowych projektach jakie przeglądarki);
  • Czy istnieje możliwość wykorzystania testów automatycznych, jeśli tak to jakich i czy będą to testy jednorazowego czy wielokrotnego użytku;
  • Czy należy przeprowadzić testy wydajnościowe;
  • Czy są jakieś obostrzenia prawne(np. RODO);
  • Ile czasu poświęcić na testy eksploracyjne;
  • Ile czasu jest przeznaczonego na testy;

Im więcej pytań postawimy na początku tym lepiej będziemy mogli dopasować nasze testy do danego projektu. Nie ukrywam, że bardzo pomocne w tym przypadku jest doświadczenie.

Przykładowe techniki stosowane w tej fazie:

  • testy dokumentacji,
  • proponowanie usprawnień,
  • rozdzielenie zadań w zespole (jeśli jest ich więcej niż 1),
  • tworzenie przypadków testowych w oparciu o dokumentację,
  • review przypadków testowych przez pozostałych członków,
  • zaplanowanie testów wydajnościowych (jeśli możliwe),
  • zaplanowanie testów automatycznych (jeśli możliwe),
  • uwrażliwienie programistów, że jeśli podejrzewają, że zmiany w module A wpłyną na moduł B to warto by o tym wspomnieli,
  • review pomysłów z osobami kluczowymi, które nie są testerami (przykładowo: kierownik projektu, analityk biznesowy, doświadczony programista)

Faza 2: Faza testów

Testy zostały zaplanowane, więc teoretycznie nie pozostaje nic innego jak tylko podążać zgodnie z planem.

Nic bardziej mylnego.

Podczas procesu testowania zespół zgłasza błędy, warto się temu przyjrzeć; co to za błędy, gdzie one występują i jakiej są natury. Część z Was pewnie kojarzy z ISTQB zasadę kumulowania się błędów, która mówi, że w niewielka liczba modułów zawiera większość błędów. Dlatego, jeśli trafimy na taki moduł, warto przedyskutować z zespołem rozszerzenie testów w danym obszarze. Zaplanowane testy również można priorytetyzować. Ponieważ plan testów zakłada konkretną ilość testów na dostępną ilość zasobów w określonym czasie. Oczywiście można zakładać bufor np. urlopy. Natomiast nie jesteśmy w stanie wszystkiego przewidzieć, dlatego w krytycznych momentach należy spróbować negocjować wydłużenie czasu testowania i tą ścieżkę polecam.

W przypadku, kiedy to niemożliwe należy podjąć decyzję, z których testów można zrezygnować, najlepiej w porozumieniu z menadżerem projektu. Warto też przemyśleć czy retestów  nie przekazać innej osobie jeśli to możliwe. To pozwoli nam na nową perspektywę w kontekście danego problemu, oczywiście czas testowania może nieznacznie się wydłużyć, ale dzięki temu taki zabieg ma szansę przynieść zwiększoną jakość.

Warto poruszyć jeszcze jedną kwestię tj. jaki będzie model wytwarzania oprogramowania a co za tym idzie podejście do testowania. Mam na myśli tzw. flow testów. Możemy to rozpatrzeć na dwóch przykładach:

  1. Zespół testerski dostaje gotową aplikację, programiści jedynie mają za zadanie naprawiać znalezione błędy.
  2. Zespół testerski testuje w trakcie developmentu czyli aplikacja wciąż jest niestabilna, ale części są już gotowe do testów.

Dobór testów i metod w obu przypadkach jest różny. W pierwszym przypadku będziemy mogli przetestować szczegółowo dany moduł, ale dopiero przy drugiej turze testów skupimy się na tym czy w kontekście całego systemu dany moduł działa. Pamiętajmy, że wciąż działamy na niestabilnym środowisku więc może warto tutaj włożyć więcej pracy w testy automatyczne, które będą mogły na bieżąco zwracać nam informacje o stanie systemu. Natomiast w drugim przypadku możemy zastosować od razu szczegółowe testy modułu wraz z testami integracyjnymi i systemowymi.

Faza podsumowania

Jak to w każdym projekcie przychodzi czas zakończenia testów i czas podsumowań. Nie rezygnujcie z tego mimo napiętego grafiku. Jest to bardzo cenny czas w projekcie, pozwala nam na przeanalizowanie minionej sytuacji i przemyślenie co mogło pójść lepiej. Dzięki temu wyniki takiej retrospektywy mogą być cennym wkładem do fazy planowania przy następnym projekcie.

W tej fazie warto wziąć pod uwagę:

  • informacje zwrotne od pozostałych zespołów,
  • listę zgłoszeń wewnętrznych,
  • listę zgłoszeń klienta - jeśli jest dostępna,
  • co zostało przetestowane,
  • użyte metryki testowe,
  • kluczowe funkcje testowania w projekcie,
  • ciekawsze przypadki(np. bardzo niestandardowy błąd)
  • przegląd testalii (czyli dokumentów, środowisk, skryptów, baz danych, procedur), które powstały w trakcie trwania projektu czy istnieje możliwość ich rozwijania lub czy mogą zostać wykorzystane w przyszłości.

Zdecydowanie warto sporządzić raport, który będzie podsumowaniem projektu pod kątem testowania.

Dobieranie testów jest jak dobre planowanie podróży samochodem. Jeśli planujemy trasę, zwracamy uwagę na różne czynniki tak, aby trasa, którą pojedziemy spełniała nasze oczekiwania (np. odległość, przystanki, czas, koszt). Czas podróży to wciąż etap, w którym potencjalnie będziemy musieli rozplanować drogę ze względu na roboty drogowe, czy wymianę opony.

Dokładnie tak samo jest z testami. Dobre plany pozwalają nam na bycie przygotowanym, natomiast cały czas musimy być gotowi do zmiany planów. Warto jest poświęcić więcej czasu na przygotowania niż próbować testować tylko eksploracyjnie na wymyślonych na poczekaniu przypadkach testowych.