Testy regresji a retesty

Przede wszystkim pamiętajmy, że największa organizacja certyfikująca testerów preferuje zamiast pojęcia „retestowanie” używanie pojęcia „testowanie potwierdzające”, a zamiast „testowania regresyjnego” czy też „testowania regresywnego” pojęcie „testowanie regresji”. Różnice może nie są duże, ale skoro już są w tym zakresie silne rekomendacje, to warto się ich trzymać. 

Testowanie potwierdzające

Jest to rodzaj testu związanego ze zmianą przeprowadzonego po naprawieniu defektu w celu potwierdzenia, że awaria spowodowana przez ten defekt już nie występuje. W praktyce testowanie ujawnia awarie, a ich zaraportowanie powinno skutkować poprawką. To, czy poprawka rzeczywiście zadziałała, sprawdzi właśnie testowanie potwierdzające. Retest jest więc tutaj ponownym uruchomieniem testu, który przy pierwszym uruchomieniu zakończył się niepowodzeniem (ang. fail).

Jeśli podczas uruchomienia przypadku testowego otrzymaliśmy rezultat „fail”, to zgłaszamy raport defektu, do którego podpinamy przypadek testowy, który zakończył się niepowodzeniem. Jeśli projekt decyduje, że defekt otrzyma poprawkę, to w kolejnej wersji raportujący dostaje w narzędziu zarządzania defektami prośbę o wykonanie retestu. Zakładamy, że po ponownym uruchomieniu przypadku testowego powinien on zakończyć się powodzeniem (ang. pass). Oczywiście istnieje możliwość, że retest ponownie zakończy się niepowodzeniem, więc całość działań będzie powtarzana w pętli aż do uzyskania rezultatu pozytywnego.

Jeśli defekt znaleziony jest w testowaniu eksploracyjnym lub podczas innej nieudokumentowanej formy testowania, to raport defektu musi szczegółowo opisywać kroki reprodukcji. Dzięki temu programista będzie mógł łatwiej przygotować poprawkę, a osoba retestująca łatwiej sprawdzi czy poprawka działa. ISTQB® rekomenduje, aby każdy raport defektu miał swój przypadek testowy, ale nie jest to powszechna praktyka. 

Testowanie regresji

Jest to rodzaj testowania związanego ze zmianami, mający na celu wykrycie, czy defekty zostały wprowadzone lub odkryte w niezmienionych obszarach oprogramowania. W praktyce chodzi o przypadek weryfikacji czy defekty nie pojawiły się w obszarach, które już wcześniej uznaliśmy za poprawnie działające. Regres w oprogramowaniu występuje z wielu powodów: mogą być to zmiany kodowe w obszarach potencjalnie niezwiązanych z tym, który przestaje działać, zmiany w środowisku pracy aplikacji (jak aktualizacja systemu operacyjnego) lub inne czynniki, które wpływają na destabilizację obszaru, który uznaliśmy za działający. W projektach często tworzy się zestawy testów regresji, które uruchamiane są na każdej kolejnej wersji oprogramowania. Ponieważ testy te są powtarzalne i w miarę niezmienne, często podlegają automatyzacji.

Niepowodzenie w uruchomieniu testów zarówno regresji, jak i dymnych jest sygnałem o pewnym poziomie nieefektywności w procesie wytwarzania oprogramowania. 

Pewną formą testowania potwierdzającego i regresji jest testowanie dymne, które jest niewielkim zestawem testów dedykowanych głównym funkcjonalnościom. 

Cechy testowania potwierdzającego i regresji w formie tabeli

Oba rodzaje testów należą do najważniejszych wykonywanych przez testerów zaraz po podstawowych, które potwierdzają, że oprogramowanie działa lub tych, które ujawniają defekty. Pojawienie się tych testów w jednym koszyku wynika z ich silnego powiązania z defektem lub próbą ustrzeżenia się przed nim. Oba są zawsze drugim i kolejnym uruchomieniem testu podstawowego.