Czym są testy związane ze zmianami i jak dobrze dobrać przypadki testowe w regresji? I czy ogóle testowanie regresji jest koniecznością, czy może jednak stratą czasu? Heraklit z Efezu twierdził, że „jedyną stałą rzeczą w życiu jest zmiana”. Grecki filozof żyjący 2500 lat temu raczej nie spodziewał się, że będzie cytowany w kontekście zmian w oprogramowaniu. Trudno mu się dziwić, jak powszechnie wiadomo nic w życiu nie jest pewne. No chyba, że błędy w kodzie. Jednak błędów związanych z modyfikacjami można uniknąć. Kluczem będzie tu odpowiedni dobór przypadków testowych do testów regresji i zapewnienie optymalnego obszaru testowania.

Wprowadzenie – testy regresji

Zacznijmy najpierw od teorii. Słownik wyrażeń związanych z testowaniem, wykorzystywanych w sylabusie podaje taką definicję testowania regresji:

testowanie regresji - rodzaj testowania związanego ze zmianami mającego na celu wykrycie, czy defekty zostały wprowadzone lub odkryte w niezmienionych obszarach oprogramowania.’

Mamy tu jasno postawiony cel: ponowne wykonanie przeprowadzonych wcześniej testów. Dzięki czemu możliwe jest sprawdzenie, czy nie pojawiły się nowe defekty w wyniku dodania kolejnych funkcjonalności czy zmian (zmiany te mogą tyczyć się oprogramowania, konfiguracji, kodu, środowisk etc.) 

Hipotetyczna sytuacja, ale z jak najbardziej możliwym scenariuszem: przeprowadziliśmy już testy konkretnego komponentu, które zakończyły się pozytywnie. Po egzekucji testów, czyli ich wykonaniu, klient zażyczył sobie pewnych modyfikacji – chce zmienić działanie jednego obszaru, który jest powiązany z inną częścią naszej aplikacji. Zmiany zostały wprowadzone przez programistę i teraz my, testerzy, przystępujemy do działania. Naszym zadaniem jest ponowne sprawdzenie funkcjonalności i dowiedzenie przy użyciu testów regresji, że wykonana wcześniej zmiana nie przyniosła efektów ubocznych w postaci defektów tam, gdzie wcześniej wszystko działało poprawnie.

Najprościej mówiąc: sprawdzamy czy jest regres, czy progres. 

Kiedy testowanie regresji jest wymagane? Jeśli mamy do czynienia między innymi ze zmianami wymagań i kodu oprogramowania, nowymi funkcjami dodanymi do oprogramowania oraz naprawą przetwarzania. Reasumując, ważne jest, żeby testy regresji były prowadzone tak często, jak wydawane są nowe kompilacje, nawet jeśli wprowadzone zmiany są niewielkie. 

Co istotne, testy regresji mogą występować na wszystkich etapach poziomów testów. Poziom testów modułowych, integracyjnych, systemowych, akceptacyjnych – zmiany mogą zostać wprowadzone na każdym z nich, a to oznacza, że na każdym poziomie mogą pojawić się nowe defekty. Niezależnie czy mamy do czynienia z testami funkcjonalnymi, niefunkcjonalnymi czy strukturalnymi. 

Proces testowania regresji

Proces testowania regresji oprogramowania obejmuje kilka uporządkowanych kroków. Zaczyna się on od analizy zmian oprogramowania. Gdy już ustalimy w jakim kierunku powinna działać zmiana, musimy przeanalizować jaki wpływ wywierają te zmiany i jakich obszarów dotykają. Oceniamy ryzyko i oszacujemy jego skutki. Kolejnym etapem naszego procesu jest definicja strategii testowania – zgodnie z zasadą ,,pracuj mądrze, nie ciężko’’ 

Nadaj priorytet swoim testom – w zależności od tego jak często używane są poszczególne funkcje i jak krytyczne byłoby dla aplikacji, gdyby przestały działać. W przypadku istniejących już przypadków, zastanów się czy aby na pewno wszystkie przypadki są aktualne – te nieaktualne nie mogą zostać wykorzystane w następnych cyklach! Tak samo jak to czy konieczne jest uruchomienie całego zestawu testów – generuje to dodatkowe koszty i wymaga większych zasobów czasu i pracy. Po zdefiniowaniu planu działania, bierzemy się za opracowywanie przypadków testowych i przeprowadzamy ją na różnych poziomach testów. Wykonujemy raport z testów i voilà! Proces testowania regresji zakończony sukcesem. 

Dobieranie przypadków na potrzeby testów regresji


Aby dobrze wybrać przypadki na potrzeby testów regresji, trzeba dokonać pewnej selekcji, ale żeby selekcja została wykonana prawidłowo, musimy kierować się pewnymi wskaźnikami. 

Takie wskaźniki to między innymi:

- podatność komponentu na błędy. Zastanów się, który obszar jest najbardziej podatny na zmiany w kodzie i odwdzięczy się masą błędów – jeśli już wiesz, który to obejmij go specjalną uwagą przez cały cykl rozwoju produktu i na pewno zastosuj testy regresyjne.

- główne funkcje aplikacji. O nich myślimy już na początku procesu testowania regresji, podczas analizy i planowania. Zaprojektuj przypadki testowe, które sprawdzają główne funkcje aplikacji. 

- przypadki testowe, które nadążają za zmianami. Wszelkie zmiany warto zapisywać w dokumentacji, aby wiedzieć jakie sytuacje uwzględnić w przypadkach testowych. 

- priorytetyzacja przypadków testowych. Priorytetyzacja może się odbywać w kryterium istotności i częstotliwości z jaką końcowy użytkownik będzie spotykał się na codzień z daną sytuacją. Testowanie regresji może sprawiać problemy, kiedy zakres obszaru do testów jest duży, a system jest ciągle rozwijany. Dlatego właśnie priorytetyzacja znacząco zmniejsza nakład pracy. 

- złożone przypadki testowe. Wszystkie przypadki, które zawierają długą sekwencję czynności, powinny zostać uwzględnione w regresji.

Regresja a retesty – jaka jest różnica?

Jeśli miałabym powiedzieć, jakie pytanie króluje w rankingu pytań z rozmów technicznych na stanowisko testera manualnego, bez wahania odpowiedziałabym, że pytanie o różnice między retestami a regresją. Nie bez powodu – z regresją i retestem będziesz w swojej pracy spotykać się codziennie. Odpowiedź na zadane wcześniej pytanie jest bardzo konkretna i łatwo zweryfikować czy kandydat orientuje się w temacie. 

Powiedzmy sobie najpierw czym jest retest. Retest to nic innego jak ponowne przetestowanie naprawionej usterki – błędu, który został wcześniej zgłoszony przez testera i naprawiony przez programistę. Retest dotyczy tylko określonego, konkretnego defektu – więc obejmuje tylko poprawioną część kodu. Potwierdza, że ​​przypadki testowe, które nie przeszły w poprzedniej wersji oprogramowania, przechodzą po usunięciu wad i odbywa się tylko dla tych, które wcześniej zakończyły się niepowodzeniem. Jeśli odtworzymy wcześniejsze kroki i okaże się, że błąd nie występuje, możemy zamknąć zgłoszenie. 

Także widzimy, że regresja to znacznie obszerniejsze zjawisko, bardziej czasochłonne – w odróżnieniu do retestu, sprawdzamy całą aplikację lub jej większą część w celu potwierdzenia, że że zmiana w kodzie nie wpłynęła negatywnie na istniejące funkcje.

Wyzwania związane z testami regresji

W oparciu o wcześniejsze rozważania możemy wymienić główne wyzwania z jakimi mierzy się tester w kontekście testowania regresji. 

Jednym z nich są duże zestawy testów. Każda kolejna regresja sprawia, że zestawy testów rosną. Każdy projekt ma swoje ograniczenia budżetowe i czasowe. Dlatego zależy nam na możliwie największej minimalizacji liczby sesji testowych przy przy równoczesnym osiągnięciu maksymalnego pokrycia. 

Musimy sobie również odpowiedzieć na pytanie, czy testować mamy po każdej, mniejszej zmianie czy po wielu poprawkach, wydaniach? Jeśli wiemy z czym się mierzymy i jakie pułapki na nas czekają, zdecydowanie łatwiej jest nam się na nie przygotować

Podsumowując, testowanie regresji jest bardzo ważnym procesem - bez względu na to czy projekt jest prowadzony w podejściu kaskadowym czy też agile. Każdym nowy przyrost oprogramowania może przynieść ze sobą regres - coś, co wcześniej było testowane i poprawnie działało mogło zostać zepsute.

Testowanie regresji może przyjmować zarówno formę weryfikacji, jak i walidacji. Jaka jest różnica między weryfikacją, a walidacją? Na to pytanie najlepiej odpowiedzieć pytaniami.

Z weryfikacją mamy do czynienia, gdy próbujemy odpowiedzieć na pytanie: „Czy produkt tworzony jest prawidłowo?”, a z kolei z walidacją: „Czy tworzony produkt jest prawidłowy?”. Weryfikacja jest ściśle powiązana z założeniami, wymogami, natomiast walidacja sprawdza czy stworzony produkt spełnia potrzeby i wymagania użytkownika.

Testy regresyjne są istotnym elementem pracy nad jakością produktów cyfrowych. Jeśli Twoje oprogramowanie jest nastawione na rozwój, testy regresji są Twoim największym sprzymierzeńcem! A przynajmniej powinny.