Porównanie retestów z testami regresyjnymi
Porównanie testów regresywnych z retestami

Wyobraź sobie, że jesteś na rozmowie rekrutacyjnej, starasz się o pracę testera oprogramowania w firmie, w której odbywa się spotkanie. Jeden z rekruterów mówi “Proszę porównać testy regresywne (regresja) z retestami”. Zgodnie z tym co udało mi się zebrać w grupie Facebookowej “Tester oprogramowania wsparcie na starcie”, takie pytanie pada często podczas rozmowy rekrutacyjnej. Dlatego dzisiaj krótko, rzeczowo i na temat o tych właśnie testach. Zaczniemy od definicji.

Retestowanie to (według słownika testerskiego sjsi.org)

Testowanie polegające na uruchomieniu przypadków testowych, które podczas ostatniego uruchomienia wykryły błędy, w celu sprawdzenia poprawności naprawy.

Tłumacząc w sposób prosty retesty polegają na tym, że Ty jako użytkownik masz sprawdzić, czy defekt (w definicji przypadek testowy) naprawiony przez programistę został poprawiony. O retestowaniu wspomniałem w artykule o cyklu życia błędu do którego przeczytania zachęcam. Opisując kilkoma zdaniami cykl życia błędu zaczyna się od zgłoszeniu defektu. Następnie programista weryfikuje go i jeśli błąd jest faktycznie błędem, poprawia go. Kod poprawiający błąd zostaje dodany (podmieniony) w aplikacji i tak zostaje on przekazany do weryfikacji testerowi. Zwykle tester retestujący jest też tym kto zgłosił błąd. W ramach retestu my testerzy sprawdzamy, czy błąd tak jak jest opisany w krokach testowych występuje nadal w aplikacji. Jeśli nie to zamykamy zgłoszenie. W sytuacji, gdy udaje się nam go odtworzyć, trafia on do poprawy. Zdarza się, że programista, poprawiając jedną rzecz, wprowadził błąd w innej funkcjonalności. W takiej sytuacji zamykamy istniejący błąd i zgłoszamy nowy.

Uważam, że dobrą praktyką w ramach wykonywania retestów jest sprawdzenie obszaru dookoła naszej ścieżki testowej. Jest to związane z jedną z ogólnych zasad testowania „kumulowanie się błędów”.

Testy regresywne to (źródło sjsi.org)

Ponowne przetestowanie uprzednio testowanego programu po dokonaniu w nim modyfikacji, w celu upewnienia się, że w wyniku zmian nie powstały nowe defekty lub nie ujawniły się wcześniej nie wykryte w nie zmienionej części oprogramowania. Testy takie są przeprowadzane po zmianach oprogramowania lub jego środowiska pracy.

Jest to bardzo obszerne sprawdzenie całego programu lub jego większej części. W celu zrozumienia, jak duże to może być zadanie, wyobraź sobie dowolną aplikację na telefon do robienia zdjęć. Pomyśl o jej funkcjonalnościach – zrób zdjęcie, edycja, usuwanie, udostępnienie zdjęć, filmowanie, przeglądanie i tak dalej. Teraz pomyśl o tym, ile przypadków testowych można napisać dla każdej z tych funkcjonalności. Dla samej tylko funkcjonalności zrobienia zdjęcia można by napisać następujące przypadki – zoom in, zoom out, zrób zdjęcie, zrób serię zdjęć, nałóż filtry, focus. Jeśli przez chwilę zastanowiłeś się nad tym małym przykładem, dla mogłoby się wydawać małej aplikacji, to powinieneś rozumieć już, że pełne testy regresywne zajmują dużo czasu.

Ponieważ “Czas to pieniądz”, przyjmujemy, że testy regresywne są bardzo kosztowne w kontekście uruchomienia ich. Z tego względu dążymy, aby oprogramowanie nie wymagało częstego ich uruchamiania. W tym celu możemy jako element dobrej praktyki wdrożyć zwyczaj  komunikacji z programistą, w celu ustalenia co po wprowadzeniu zmian w kodzie powinno być przetestowane. Jako, że kod został napisany przez tego właśnie developera, powinien on być w stanie powiedzieć nam, jak dużą część aplikacji musimy sprawdzić. W celu zmniejszenia kosztów testów regresywnych możemy wprowadzić do aplikacji testy automatyczne, które będą sprawdzały ścieżki przez nas opisane i weryfikowały jakość oprogramowania.

Porównanie testów regresywnych z retestami

Porównanie retestów z testami regresywnymi

W tabelce powyżej znajdziesz szybkie porównanie najważniejszych, według mnie, cech różniących retest od testów regresywnych. Poniżej znajdziesz te same cechy szerzej opisane.

Retesty Testy regresywne
Obszar
Retesty polegają na weryfikacji, czy defekty poprawione przez programistę nie występują już w aplikacji. Obszar testów ograniczony jest do tego co opisane jest w krokach testowych.
Testy regresywne najczęściej dotyczą całego systemu i wykonywane są w oparciu o przypadki testowe.
Koszt
Czas poświęcony na retest zależy od ilości defektów do weryfikacji oraz czy przy okazji weryfikujemy też przypadki testowe związane z retestowanym funkcjonalnością. Może to być zatem jeden dzień, gdy retestujemy kilkanaście błędów i testujemy obszar dookoła. Retest pojedynczego błędu dotyczącego literówki to kilka minut, ale i retest błędu, który dotyczy dużej funkcjonalności i wymaga przygotowania danych testowych, może trwać dzień. Tak więc czas trwania retestu zależy od ilości błędów oraz od tego, czego one dotyczą.
W przypadku testów regresywnych sprawdzeniu poddawany jest cały system. Dlatego testy dla dużych aplikacji trwają nawet kilkanaście osobo dni (jeśli nie dla aplikacji nie utworzono testów automatycznych).
Częstotliwość wykonania
Każdy zgłoszony błąd wymaga weryfikacji. W zależności od zwyczajów przyjętych w zespole retesty są wykonywane na bieżąco lub zgodnie z planem sprintu.
Ze względu na koszty związane z testami regresywnymi wykonywane są one wówczas, gdy zmiany zrobione w systemie wymagają weryfikacji całej aplikacji.
Czy wykonywane są testy automatyczne?
Zwykle nie. Dobrą praktyką jest jednak tworzenie przypadków testowych i jeśli to możliwe automatyzować błędy poważne.
I tak i nie. Dla dużej aplikacji ze stabilnym kodem dobrze jest mieć utworzone testy automatyczne.
Po co wykonujemy?
Celem retestów jest weryfikacja czy defekt jest poprawiony.
Testy regresywne wykonujemy by potwierdzić, że zmiany dokonane w aplikacji nie spowodowały powstania błędów.
Podsumowanie

Mam nadzieję, że po przeczytaniu tego artykułu bez problemu odpowiesz na pytanie rekrutacyjne, czym różni się retest od testów regresywnych. Jeśli jesteś na etapie nauki zawodu testera oprogramowania, zachęcam Cię do przeczytania innych artykułów na moim blogu dotyczących testowania oprogramowania.

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz

Zamknij