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.

Mity na temat testowania oprogramowania

Przetestowanie całej aplikacji/systemu jest możliwe. Jeśli testy zostaną odpowiednio zaplanowane to możliwe jest znalezienie i poprawienie wszystkich błędów w aplikacji.
Oprogramowanie zawiera coraz więcej linii kodu, staje się coraz bardziej złożone. Coraz więcej aplikacji współpracuje ze sobą w ramach jednego, rozproszonego systemu. Pokrycie testami wszystkich ścieżek przejścia we wszystkich kombinacjach jest niemożliwe choćby z powodu ograniczeń związanych z budżetem i czasem.

Kiedy projekt zakłada, że po ostatniej fazie testów aplikacja będzie wolna od błędów, dział testów staje się odpowiedzialny za każdy problem znaleziony w wersji produkcyjnej. Z kolei próba przetestowania wszystkich aspektów tworzonej aplikacji spowoduje opóźnienie w dostarczeniu wersji produkcyjnej. W rzeczywistości prawie każda aplikacja zawiera błędy. Pytanie, jakiego są one rodzaju i jak często objawiają się w np. niestabilnym działaniu gotowego produktu.

Testy powinny być przeprowadzane w pełni skonfigurowanym środowisku.
Im bardziej środowisko testowe przypomina docelowe środowisko produkcyjne, tym bardziej można polegać na wynikach testów. Jeśli środowisko produkcyjne klienta jest przez niego w pełni kontrolowane, testowanie może odbywać się w jak najbardziej zbliżonych warunkach. Jeśli tak nie jest, testy przeprowadzone w pełni skonfigurowanym środowisku mogą spowodować, że ważne przypadki testowe mogą w ogóle nie powstać.

Testowanie jest potrzebne, aby udowodnić, że oprogramowanie nie zawiera błędów.
Testowanie samo w sobie nie służy do poprawienia jakości aplikacji, ale jest tej jakości miernikiem. Przystępując do testów nie należy robić tego z założeniem, że system działa.

Zazwyczaj przypadki testowe, których wykonanie nie spowodowało wykrycia błędu oznacza się statusami “passed”, “ok”, “tested ok”. Jednak z punktu widzenia testera to właśnie Test Case, który pozwolił na odkrycie błędu jest sukcesem.
Oprogramowanie oprócz tego, że powinno poprawnie wykonywać pożądane i zaimplementowane funkcjonalności, nie powinno pozwalać na operacje, do których wykonywania nie zostało stworzone.

Automatyzacja testów. Jeśli można coś zautomatyzować należy to zrobić.
Automatyzacja jest potrzebna. Oszczędza nam, testerom długich wieczornych godzin spędzonych przy manualnych testach regresywnych. Z kolei estymowana liczba godzin na testy manualne, może skłonić projekt do zainwestowania w automatyzację testów.

Jednak co z czasem spędzonym na nauce narzędzi do testów automatycznych, tworzeniu skryptów i ich aktualizacją? Jedynie odpowiednia kombinacja testów automatycznych, testów eksploracyjnych i manualnych testów wykonywanych na podstawie przypadków testowych może spowodować, że informacja o jakości testowanego oprogramowania będzie kompletna i wiarygodna.