Gdy zespół wdraża poprawkę defektu w obliczaniu płatności, najpierw uruchamia ponownie testy, które wcześniej zakończyły się niepowodzeniem (to retestowanie), a następnie wykonuje pełny zestaw testów regresji obejmujący pozostałą część procesu finalizacji zakupu. Testowanie regresji potwierdza, że obszary, w których nic się nie zmieniło — takie jak logika rabatów czy obliczanie kosztów dostawy — nadal działają poprawnie po wprowadzonej modyfikacji. W integracji ciągłej testy regresji zwykle uruchamiają się automatycznie po każdej zmianie w kodzie.
Jaka jest różnica między testowaniem regresji a retestowaniem? Retestowanie polega na uruchomieniu konkretnych przypadków testowych, które ostatnio zakończyły się niepowodzeniem, aby zweryfikować, czy poprawka zadziałała. Testowanie regresji uruchamia testy na wcześniej przetestowanej, niezmienionej funkcjonalności, aby upewnić się, że zmiana nie wprowadziła nowych defektów. Po każdej poprawce potrzebne są oba rodzaje testów.
Kiedy wykonuje się testowanie regresji? Za każdym razem, gdy zmienia się oprogramowanie lub jego środowisko: pojawiają się nowe funkcje, poprawki błędów, zmiany konfiguracji lub aktualizacje infrastruktury. Im większa zmiana, tym ważniejsze jest pokrycie testami regresji.
Ile testowania regresji wystarczy? Tyle, ile potrzeba, aby pokryć ryzyko związane ze zmianą. Zespoły często zaczynają od przejścia testami dymnymi przez ścieżki krytyczne, a następnie rozszerzają zakres w oparciu o wpływ zmiany i dostępną automatyzację testów.
Czy testowanie regresji to poziom testów? To typ testów, a nie poziom — testy regresji można wykonywać na każdym poziomie, od testowania komponentów po testowanie systemowe, i często pojawiają się w wielu fazach.
