Testy regresyjne

Testy regresyjne (ang. regression testing) to powtarzalne testy sprawdzające, czy modyfikacja oprogramowania nie spowodowała regresji — czyli ponownego pojawienia się błędu lub zepsucia funkcji, która wcześniej działała poprawnie. Nazwa opisuje nie technikę pisania testu, lecz cel jego uruchomienia: upewnienie się, że nowe zmiany niczego nie popsuły w istniejącej części systemu.

Na czym polega testowanie regresyjne?

Za każdym razem, gdy do kodu trafia nowa funkcja, poprawka lub refaktoryzacja, istnieje ryzyko, że przy okazji uszkodzi ona pozornie niezwiązany element — bo współdzielą one funkcję, dane lub stan aplikacji. Aby to wychwycić, uruchamia się ponownie wcześniej napisane testy jednostkowe, integracyjne oraz end-to-end. Jeśli wcześniej zielony test nagle świeci na czerwono, oznacza to regresję do naprawienia przed wdrożeniem. Przy dużych projektach pełny pakiet potrafi trwać godzinami, dlatego stosuje się selekcję testów (uruchamianie tylko tych powiązanych ze zmianą) oraz priorytetyzację. Osobnym zjawiskiem jest regresja wizualna, w której porównuje się zrzuty ekranu interfejsu, by wykryć niezamierzone zmiany wyglądu.

Zastosowanie w praktyce

Testy regresyjne mają sens tylko wtedy, gdy są zautomatyzowane i uruchamiane systematycznie — ręczne powtarzanie setek scenariuszy po każdej zmianie jest niewykonalne. Dlatego wpina się je w potok CI/CD: każdy commit automatycznie odpala cały zestaw, a nieudany test blokuje wdrożenie. Dobrą praktyką jest też reguła, że po wykryciu każdego nowego błędu najpierw pisze się test odtwarzający go, a dopiero potem poprawkę — dzięki temu ten sam błąd nigdy nie wróci niezauważony. W efekcie rosnący pakiet regresyjny działa jak siatka bezpieczeństwa, która pozwala zespołowi śmiało zmieniać kod bez obawy o zepsucie działających funkcji.