Testowanie regresywne

Każde oprogramowanie jest co jakiś czas odświeżane, rozszerzane i zmieniane. Zmiany w kodzie mogą dotyczyć wielu aspektów, m. in.: dodawania, usuwania lub modyfikowania funkcji, adaptacji oprogramowania do nowych warunków, systemów czy umożliwienia wykorzystania nowych technologii, narzędzi i algorytmów razem z oprogramowaniem. Niestety takie modyfikacje mogą zmieniać działanie oprogramowania, spowalniać je lub wręcz wywołać awarie systemu w funkcjonalnościach, które dotychczas działały prawidłowo.

Aby zapobiec negatywnym skutkom zmiany oprogramowania, testerzy oprogramowania wykorzystują testy regresywne, które pozwalają wykryć błędy w oprogramowaniu spowodowane zmianami w kodzie.

Czym jest testowanie regresywne?

Regresja to z definicji “powrót do poprzedniego stanu”, a testy regresywne to “testy takie same, jak w stanie poprzednim” – testowanie regresywne to więc nic innego jak testowanie funkcjonalności poprzednio testowanych i ocenionych jako niezawierające błędów. Często wykorzystuje się w nich zestawy testów stworzone i używane na wcześniejszych etapach prac.

Testowanie regresywne dotyczy nie tylko nowo wprowadzonych zmian w kodzie, ale przede wszystkim “starych” funkcjonalności, które mogły zostać uszkodzone “przy okazji” wprowadzania modyfikacji. Chodzi o wykrycie nie tylko całkowitych awarii oprogramowania, ale także drobnych błędów w poszczególnych funkcjach oraz spadku wydajności działania programu. 

Jak stwierdzić, co należy przetestować regresywnie?

Testowanie regresywne może być niezwykle pracochłonne i czasochłonne. Łatwo uzmysłowić sobie, że konieczność powtarzania wszystkich testów przeprowadzanych na poprzednich etapach przy wprowadzaniu każdej nowej modyfikacji kodu jest niezwykle uciążliwa. Dlatego też bardzo rzadko testowanie regresywne polega właśnie na tym. Szczęśliwie dużą część testów regresywnych da się przeprowadzić automatycznie, a udział człowieka jest konieczny jedynie do zaprojektowania testów i – ewentualnie – oceny wyników. Testy regresywne to właśnie ten rodzaj testów, który najczęściej się automatyzuje. Zwykle są to testy warstwy frontowej (User Interface) i warstwy backendowej – test API.

Istnieją trzy podstawowe techniki dobierania “zbiorów testowych”, czyli przypadków testowych, które zostają powtórzone w ramach testów regresywnych:

–  Regresywne testowanie wszystkiego. Obranie tego podejścia oznacza, że wszystkie testy systemu i jego funkcjonalności zostają przeprowadzone od nowa. Jest to najpewniejszy sposób, by upewnić się, że wszystko działa bez zarzutu, jednak wymaga on niezwykle dużo czasu i zaangażowania. Praktyka testowania wszystkiego od nowa jest rzadko stosowana, a jeśli już testerzy decydują się na nią, zazwyczaj automatyzują większość testów.

–  Wybiórcze testowanie regresywne. Wybierając podzbiór istniejących (wykorzystywanych na poprzednich etapach) przypadków testowych, specjalista ds. kontroli jakości (ang. QA specialist) może znacznie obniżyć koszty operacyjne testowania regresywnego. Istnieje kilka praktyk stosowanych do wyboru przypadków testowych, które posłużą do regresywnego testowania oprogramowania. 

Można na przykład testować jedynie tę część oprogramowania, której dotyczą wprowadzonej zmiany. Innym popularnym podejściem jest testowanie przypadków, które na wcześniejszych etapach generowały błędy. Wybierając przypadki testowe można również posługiwać się technikami opierającymi się na przepływie danych lub doborem losowym. 

Priorytetyzacja przypadków testowych. W tym podejściu tester koncentruje się na testowaniu najczęściej używanych funkcji i przypadków, które mają największy wpływ na użytkowanie oprogramowania. Czasowe odłożenie na bok wszystkich funkcji wtórnych i mało popularnych, niezwykle specyficznych przypadków pozwala znacząco zmniejszyć zbiór testów i skupić się na kluczowych elementach oprogramowania.

Co sprawdzają testy regresywne?

Testy regresywne przeprowadza się zarówno na etapie tworzenia oprogramowania, jak i po wypuszczeniu go na rynek / oddaniu klientowi: należy je wykonywać przy każdej zmianie w kodzie źródłowym oprogramowania, a więc po każdej modernizacji, pracach utrzymaniowych, dodaniu funkcji czy przystosowaniu do innego oprogramowania. Nie służą jednak temu, by upewnić się, że to nowe funkcjonalności działają jak trzeba – skupiają się na tych starych, dotychczas działających poprawnie. Po co więc się je robić?

Aby utrzymać dobrą wydajność działania programu. Wprowadzenie nowej funkcji może wpłynąć na cały system – niekoniecznie w dobry sposób. Testerzy przeprowadzają sesje testowania regresywnego, aby upewnić się, że wydajność systemu nie spadła po modyfikacji kodu.

Aby sprawdzić wydajność aplikacji po dodaniu nowej funkcji. Testy regresywne pozwalają programistom upewnić się, że nowe funkcje dobrze współdziałają ze starymi, a cała infrastruktura produktu jest w stanie wykonywać bardziej złożone działania bez utraty prędkości działania ani awarii.

Aby zidentyfikować części aplikacji, które są najbardziej narażone na awarię. Testy regresywne pomagają programistom zrozumieć, które elementy systemu są najbardziej podatne na zmiany i są najbardziej narażone na awarię. Z kolei testerzy mogą dowiedzieć się, na jakie funkcjonalności powinni zwracać szczególną uwagę w przyszłości. 

Rodzaje testów regresywnych

Testy regresywne mogą wyglądać bardzo różnie: nie ma jednego zdefiniowanego podejścia, które z góry narzucałoby, jak ma wyglądać każdy zestaw testów regresywnych. Poza podziałem ze względu na rozmiar i skład zestawu testowego (zestawu testowanych przypadków), można podzielić testy regresywne ze względu na to, co konkretnie mają sprawdzić. Najpopularniejsze stosowane podejścia to: 

Korygujące testy regresywne. To podejście jest stosowane, gdy program nie został znacząco zmieniony. W przypadku takich sesji programiści rzadko piszą nowe przypadki testowe – zamiast tego ponownie używają starych.

Progresowe testy regresywne. To podejście służy do testowania wpływu nowego komponentu na system. Aby zastosować progresywne testy regresywne, zespół testujący powinien być świadomy dokładnej liczby i charakteru zmian wprowadzonych w kodzie. Rzecz jasna do tego typu testów trzeba napisać nowe przypadki.

Selektywne testy regresywne. Stosując to podejście tester wybiera zakres przypadków testowych w celu przyspieszenia prac. Pozwala ono zaoszczędzić czas i pracę, a co za tym idzie – pieniądze, jednak wyzwaniem jest ustalenia zakresu i charakteru przypadków testowych.

Kompletne testy regresywne. Takie podejście jest zwykle stosowane, gdy programistom trudno określić liczbę wprowadzonych zmian lub ich wpływ na resztę oprogramowania. Może się tak zdarzyć na przykład w przypadku dużych zmian w kodzie czy przystosowywaniu oprogramowania do nowych systemów. Kompletne testy regresywne dają specjalistom ds. kontroli jakości oprogramowania pełen obraz systemu jako całości. Takie testy zazwyczaj są przeprowadzane na końcowych etapach pracy nad oprogramowaniem przed wypuszczeniem wersji. 

Autor: Tomasz Stelmach

Notatka o autorze:

Zajmuję się testowaniem, zabezpieczaniem i zapewnianiem jakości oprogramowania od ponad 13 lat. Rozpocząłem swoją karierę od testów manualnych i analizy biznesowo-technicznej. Obecnie prowadzę firmę Quality Island, która zajmuje się szeroko pojętym testowaniem oprogramowania oraz szkoleniami dla przyszłych i obecnych testerów oprogramowania. Moją specjalnością są testy automatyczne aplikacji webowych oraz budowa procesów automatyzacji i robotyzacji. Od 8 lat prowadzę aktywnie szkolenia oraz konsultacje z tych tematów i wykonuję zlecenia dla firm trzecich jako konsultant, ekspert oraz audytor. Współpracuję również z firmami jako osoba do rekrutacji i weryfikacji technicznych. Interesują mnie głównie tematy związane z architekturą IT oraz zagadnienia DevOps/TestOps, ponieważ ściśle wiążą się z zapewnianiem jakości oprogramowania.

 

Tomasz Stelmach

CEO&Founder

 

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *