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.
słownik testerski sjsi.org
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łoszenia 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łaszamy 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.
źródło sjsi.org
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.
Tabelka obrazuje czym różnią się testy regresywne od retestów
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 retestowaną 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.
Jeśli trafiłeś na mojego bloga, ponieważ przygotowujesz się do rozmowy rekrutacyjnej, to możesz być zainteresowany moim e-bookiem, w którym opisuję odpowiedzi na 105 pytań, jakie możesz dostać na rozmowie rekrutacyjnej na testera oprogramowania.
Zgadzam się z Pauliną, tester nie może przekazywać nierzetelnej informacji.
Rolą testera jest rzetelne informowanie interesariuszy – „przetestowano, błędów nie wykryto”. To nie jest „dupokryjka” to jest wiarygodna informacja. Ze względów ekonomicznych nie ma możliwości przetestowania „wszystkiego” zatem komunikat „przetestowałem, błędów nie ma” jest komunikatem wprowadzającym błąd odbiorcę.
Dziękuję,
Pozdrawiam,
Cześć, bardzo dziękuję za zamieszczone porównanie oraz czytelne tabele. Mam jednak wątpliwość, co do sformułowania zamieszczonego w uproszczonej wersji tabeli (na przecięciu się „celu” i „regresji”), które brzmi „potwierdzenie, że w aplikacji nie ma błędu”. Stwierdzenie to sugeruje, że aplikacja jest wolna od błędów, a takie przekonanie jest niezgodne z sylabusem ISTQB („Przekonanie o braku błędów jest błędem”).
Cześć! Dzięki za super komentarz 🙂
nie czytałbym tego w tak dosłowny sposób – wiadomo, że bardzo ciężko a pewnie w realnym świecie jest niemożliwe wyeliminowanie błędów. W sumie tak jak czytam po raz drugi Twój komentarz to stwierdzam, że faktycznie jest to zbyt spłycone i muszę to przerobić 🙂