Kiedy należy przestać testować

Testować potencjalnie można bez końca. Nie możemy jednak kontynuować testów do momentu znalezienia ostatniego błędu w systemie. To oczywiście niemożliwe.

W pewnym momencie należy przerwać i dostarczyć system do klienta. Pytanie brzmi, kiedy uznać, że oprogramowanie jest wystarczająco dobrze sprawdzone.

Testowanie mieści się pomiędzy budżetem projektu, czasem na jego realizację i jakością dostarczanego rozwiązania. Project Triangle

Pesymistyczny scenariusz zakłada przerwanie testowania w momencie, kiedy jeden z trzech wymienionych zasobów ulegnie wyczerpaniu.

Przykłady:

  • zbliżająca się data wypuszczenia oprogramowania na rynek
  • wyczerpany budżet projektu
  • upłynięcie czasu przeznaczonego na testy Alfa, Beta
  • założony procent wykonanych przypadków testowych uzyskał status “passed”.
  • pokrycie kodu/funkcjonalności/wymagań, osiągnęło założony poziom
  • liczba wykrywanych błędów spadła poniżej zakładanego progu

W optymistycznej wersji zakończenie testów następuje gdy:
– oprogramowanie spełnia założone wymagania jakości
– korzyści z kontynuowania testów przestają rekompensować koszty ponoszone na testowanie

Przykłady:

  • częstotliwość występowania błędów jest na akceptowalnym (wystarczająco niskim) poziomie
  • pokrycie kodu,funkcjonalności,wymagań osiągnęło pożądany procent
  • liczba wykonań przypadków testowych, ukończonych sukcesem jest na pożądanym poziomie

Kiedy zakończyć testowanie aplikacji

Moment zakończenia testów oprogramowania może być trudny do określenia. Współczesne aplikacje są złożone, pracują w rozproszonym środowisku i składają się z wielu współpracujących podsystemów. Teoretycznie testy mogą trwać przez cały  SDLC oraz w fazie utrzymania.
Są jednak czynniki, które pomagają zdecydować o zakończeniu testów:

  • czas (data uruchomienia w środowisku produkcyjnym, data zakończenia testów aplikacji, tzw. deadline)
  • przypadki testowe (test cases) – odpowiedni procent przypadków testowych, których wykonanie nie spowodowało wykrycia błędu.
  • wyczerpanie budżetu na testy
  • pokrycie kodu, funkcjonalności, wymagań w założonym zakresie
  • krzywa wykrywania błędów poniżej założonego wcześniej progu

Kto zatem powinien podjąć decyzję o zakończeniu testowania?

Osobą odpowiedzialną za testy w organizacji jest Test Manager. Z punktu widzenia jakości to on podejmuje decyzję o tym czy system spełnia zdefiniowane wcześniej kryteria jakości, jednak z punktu widzenia projektu informacja ta jest jedną ze składowych, które brane są pod uwagę przed wdrożeniem wersji produkcjyjnej testowanej aplikacji:

  • daty uruchomienia współpracujących systemów
  • cele związane ze sprzedażą
  • sytuacja na rynku i poczynania konkurencji
  • czynniki prawne
  • oczekiwania klienta

Z powyższych wynika, że odpowiedzialnością Test Managera jest dostarczenie informacji nt jakości grupie osób odpowiedzialnych za podjęcie decyzji o “wypuszczeniu aplikacji na rynek”. W małych organizacjach/projektach taką rolę może pełnić Project Manager lub Product Manager. W dużych decyzja może być podejmowana przez grupę osób ze strony biznesu i projektu.