Oprogramowanie rzadko kiedy jest statyczne.

W trakcie jego cyklu życia nieustannie wprowadzane są zmiany – czy to w celu dodania nowych funkcjonalności, poprawienia istniejących, usunięcia wykrytych defektów, czy dostosowania do zmieniającego się środowiska.

Każda taka zmiana, nawet pozornie niewielka, niesie ze sobą ryzyko.

Ryzyko, że poprawka nie zadziałała zgodnie z oczekiwaniami, lub – co gorsza – że wprowadziła nowe, nieprzewidziane problemy w innych częściach systemu.

Aby zarządzać tym ryzykiem i utrzymać jakość oprogramowania na odpowiednim poziomie, niezbędne są dwa kluczowe rodzaje testów: testy potwierdzające (confirmation testing) i testy regresji (regression testing).

Jak podkreśla sylabus ISTQB Foundation Level v4.0, „proces testowania powinien również obejmować testowanie potwierdzające i testowanie regresji” po wprowadzeniu zmian.

W tej lekcji zgłębimy definicje, cele, strategie i znaczenie obu tych typów testów.

Testowanie Potwierdzające (Confirmation Testing / Re-testing)

Gdy zespół deweloperski informuje, że defekt został naprawiony, skąd możemy mieć pewność, że faktycznie tak jest?

Właśnie tutaj wkracza testowanie potwierdzające.

Jak definiuje sylabus ISTQB, „testowanie potwierdzające ma na celu sprawdzenie, czy pierwotny defekt został pomyślnie usunięty”.

Jest to więc bezpośrednia weryfikacja skuteczności wprowadzonej poprawki.

• Cel: Potwierdzenie, że zgłoszony wcześniej defekt został naprawiony i oprogramowanie działa teraz zgodnie z oczekiwaniami w obszarze objętym poprawką.
• Kiedy wykonywane: Po dostarczeniu przez zespół deweloperski nowej wersji oprogramowania zawierającej poprawkę zgłoszonego defektu.
• Jak wykonywane: Sposób przeprowadzenia testów potwierdzających zależy od poziomu ryzyka i dostępnego czasu. Sylabus wymienia kilka podejść:
  • Wykonanie wszystkich przypadków testowych, które wcześniej nie zostały zaliczone z powodu defektu: Jest to najbardziej kompleksowe podejście, dające największą pewność, że problem został rozwiązany we wszystkich scenariuszach, w których wcześniej występował.
  • Dodanie nowych testów w celu pokrycia ewentualnych zmian, które były niezbędne do usunięcia defektu: Czasem poprawka wymagała wprowadzenia dodatkowych zmian w kodzie lub logice. Warto wtedy zaprojektować nowe testy, aby upewnić się, że te zmiany również działają poprawnie.
  • Wykonanie kroków potrzebnych do odtworzenia awarii spowodowanej defektem i sprawdzenia, czy tym razem ona nie występuje: Jest to podejście minimalne, stosowane, gdy brakuje czasu lub środków. Polega na powtórzeniu dokładnych kroków, które prowadziły do wystąpienia błędu i sprawdzeniu, czy błąd już nie występuje. Daje to podstawowe potwierdzenie, ale nie gwarantuje, że defekt został usunięty we wszystkich możliwych kontekstach.
• Kto wykonuje: Zazwyczaj tester, który pierwotnie zgłosił defekt, lub inny członek zespołu testowego.

Testowanie potwierdzające jest niezbędnym krokiem w cyklu życia defektu.

Bez niego nie mamy formalnego potwierdzenia, że problem został rozwiązany, a defekt może zostać zamknięty.

Ważne jest, aby testy potwierdzające były przeprowadzane na tej samej konfiguracji środowiska (lub jak najbardziej zbliżonej), na której pierwotnie wykryto defekt.

Testowanie Regresji (Regression Testing)

Naprawienie jednego defektu lub dodanie nowej funkcji to jedno, ale co jeśli ta zmiana „zepsuła” coś innego w systemie, co wcześniej działało poprawnie?

Takie nieoczekiwane, negatywne skutki uboczne zmian nazywamy regresją.

Celem testowania regresji jest właśnie wykrycie takich problemów.

Sylabus ISTQB definiuje testowanie regresji jako działania pozwalające „sprawdzić, czy wprowadzona zmiana (w tym także poprawka, która była już przedmiotem testowania potwierdzającego) nie spowodowała negatywnych konsekwencji”.

Te negatywne konsekwencje mogą pojawić się w różnych miejscach:

• W module, w którym bezpośrednio wprowadzono zmianę.
• W innych modułach tego samego systemu, które w jakiś sposób zależą od zmienionego modułu lub z nim współpracują.
• W innych, zewnętrznych systemach, które są podłączone do testowanego systemu.

Dlatego, jak zauważa sylabus, „testowanie regresji może wykraczać poza przedmiot testów i obejmować również środowisko, w którym się on znajduje”.

• Cel: Wykrycie niezamierzonych skutków ubocznych (regresji) wprowadzonych zmian w oprogramowaniu. Zapewnienie, że modyfikacje nie zepsuły wcześniej działających funkcjonalności.
• Kiedy wykonywane: Po każdej zmianie w oprogramowaniu – czy to po dodaniu nowej funkcji, modyfikacji istniejącej, czy po poprawieniu defektu (nawet jeśli testy potwierdzające zakończyły się sukcesem).
• Jak wykonywane: Testowanie regresji polega na ponownym wykonaniu podzbioru wcześniej zdefiniowanych i wykonanych testów, które obejmują obszary potencjalnie dotknięte zmianą. Wybór testów do wykonania w ramach regresji jest kluczowy dla efektywności tego procesu.
• Kto wykonuje: Zazwyczaj zespół testowy, często z wykorzystaniem automatyzacji.

Optymalizacja Zakresu Testów Regresji – Analiza Wpływu

Przeprowadzenie pełnego zestawu wszystkich istniejących testów po każdej, nawet najmniejszej zmianie, jest zazwyczaj nierealistyczne i nieefektywne czasowo oraz kosztowo.

Dlatego kluczowe jest umiejętne dobranie zakresu testów regresji.

Jak zaleca sylabus, „zalecane jest przeprowadzenie w pierwszej kolejności analizy wpływu (impact analysis) mającej na celu zoptymalizowanie zasięgu testowania regresji, co pozwoli wskazać elementy oprogramowania, na które będzie mogła wpłynąć wprowadzona zmiana”.

Analiza wpływu polega na zidentyfikowaniu potencjalnych konsekwencji wprowadzonej zmiany w różnych częściach systemu.

Wymaga to zrozumienia architektury systemu, zależności między modułami, przepływów danych i potencjalnych interakcji.

Na podstawie tej analizy można wybrać te przypadki testowe, które pokrywają obszary o największym ryzyku wystąpienia regresji.

Czynniki brane pod uwagę przy wyborze testów regresji to m.in.:

• Obszary systemu bezpośrednio zmodyfikowane.
• Obszary systemu zależne od zmodyfikowanych części.
• Kluczowe, krytyczne funkcjonalności systemu.
• Obszary, w których historycznie często występowały defekty.
• Złożoność wprowadzonej zmiany.
• Dostępny czas i zasoby.

Dobrze przeprowadzona analiza wpływu pozwala na skupienie wysiłków testowych tam, gdzie są one najbardziej potrzebne, zwiększając efektywność testowania regresji.

Automatyzacja Testów Regresji

Testowanie regresji jest często powtarzalne i czasochłonne, zwłaszcza w projektach z częstymi zmianami.

Dlatego jest to idealny kandydat do automatyzacji.

Jak wskazuje sylabus, „testy regresji są często automatyzowane”.

Zautomatyzowany zestaw testów regresji może być uruchamiany regularnie (np. każdej nocy lub w ramach procesu CI/CD), zapewniając szybką informację zwrotną na temat potencjalnych regresji.

Automatyzacja pozwala na szersze pokrycie testami regresji przy mniejszym wysiłku manualnym, co jest szczególnie ważne w podejściach zwinnych i DevOps.

Podsumowanie

Testowanie potwierdzające i testowanie regresji są kluczowymi działaniami wykonywanymi po wprowadzeniu zmian w oprogramowaniu.

Testowanie potwierdzające (re-testing) weryfikuje, czy zgłoszony defekt został pomyślnie usunięty.

Testowanie regresji sprawdza, czy wprowadzone zmiany (w tym poprawki) nie spowodowały niezamierzonych negatywnych skutków ubocznych w innych częściach systemu.

Zakres testów regresji powinien być optymalizowany za pomocą analizy wpływu.

Testowanie regresji jest często automatyzowane, aby zapewnić efektywność i szybkość informacji zwrotnej.

Oba rodzaje testów są niezbędne do utrzymania jakości i stabilności oprogramowania w dynamicznym środowisku zmian.