"Wczesne testowanie oszczędza czas i pieniądze". Czy na pewno?

"Wczesne testowanie oszczędza czas i pieniądze". Czy na pewno?
7 zasad testowania ISTQB® tak bardzo utkwiło nam w głowie, że przymykamy oko na brak logiki części z nich. Jedna z podstawowych, dotycząca shift-left jest w miarę OK, ale z pewnymi założeniami.

Wczesne testowanie (ang. shift-left) jest OK. Kontrolę jakości należy zacząć w miarę wcześnie i ma to wiele zalet, o czym wspomnieliśmy tutaj.

Jednak druga część stwierdzenia nie jest już taka oczywista. Oto fragment z sylabusa ISTQB® Poziom Podstawowy w wersji 4.0, który może pomóc w jego interpretacji:

Wczesne testowanie oszczędza czas i pieniądze. Defekty usunięte na wczesnym etapie procesu nie powodują powstania kolejnych defektów w pochodnych produktach pracy. Przekłada się to na obniżenie kosztu jakości, ponieważ dzięki temu zmniejsza się liczba awarii występujących na późniejszych etapach cyklu wytwarzania oprogramowania (Boehm 1981). Aby wcześnie wykryć defekty, należy jak najszybciej rozpocząć zarówno testowanie statyczne (patrz rozdział 3), jak i testowanie dynamiczne (patrz rozdział 4)

Pomijając to, że samo twierdzenie jest oparte na publikacji z 1981 roku, ogólnie da się z nim zgodzić, gdyby nie jego twierdzący charakter. Właściwym stwierdzeniem byłoby „wczesne testowanie może oszczędzać czas i pieniądze”,  zgodnie z inną regułą testowania – „to zależy (od kontekstu)”.

Wczesne testowanie działa prewencyjnie, zapobiegając powstawaniu kosztownych awarii i opóźnień w realizacji projektu. Dzięki identyfikacji błędów na wczesnym etapie można je naprawić szybciej i taniej, co przekłada się na oszczędności i krótszy czas realizacji.

Wczesne testowanie, które nie daje rady znajdować defektów i awarii, nie będzie oszczędzało czasu i pieniędzy. Dwie kwestie mogą uniemożliwiać identyfikację anomalii:

  1. Nie znajdujemy defektów, bo nie mamy wystarczających kompetencji do wczesnego testowania. Przepalamy pieniądze bez żadnej korzyści dla projektu 
  2. Nie znajdujemy defektów, ponieważ ich tam nie ma. Przepalamy pieniądze na potwierdzanie, że dokumentacja jest OK i wstępne wersje działają. Buduje to oczywiście swoistą pewność siebie zespołu i zaufanie klienta, ale nie oszczędza nam ani pieniędzy, ani i czasu. 

Niestety samo „wczesne testowanie oszczędza czas i pieniądze” jest zachętą do wielu nieuprawnionych stwierdzeń i tez, które można podważyć już przez samo obalenie właściwego prezałożenia. Przykłady:

  • „Wczesne testowanie jest tańsze” i - co nie jest często dopowiedziane - „od późnego testowania”. Nie jest to złe stwierdzenie, choć łatwo je podważyć. Nigdy nie jest tak, że testowanie wczesne całkowicie eliminuje późne testowanie. Zazwyczaj wykonuje się oba. Do tego suma wszystkich kosztów testowania, które zaczyna się wcześnie i trwa do końca projektu, wcale nie będzie tańsze od późnego testowania. Może za to (ale nie musi) przełożyć się na niższy koszt jakości w projekcie;
  • „Wczesne testowanie jest tanie” – nie jest. Wczesne testowanie kosztuje i będzie kosztowało sporo. Korzyści płynące z niego są duże, ale tanie nie jest. Wymaga chociażby eksperckiej wiedzy;
  • „Wczesne testowanie jest ZAWSZE lepsze” – to stwierdzenie obalimy klasycznym „to zależy”, ale znów pojawia się pytanie „lepsze od czego”?

Chcąc ostatecznie odpowiedzieć na pytanie, czy wczesne testowania oszczędza czas i pieniądze, możemy stałą stanowczością powiedzieć MOŻE. 

Ale z pewnością nie da się tego ani wykluczyć, ani ostatecznie potwierdzić.  

To powinno Cię zainteresować