Testowanie regresywne (regresja) to sprawdzanie, czy nowe zmiany - funkcje, poprawki, aktualizacje bibliotek - nie zepsuły czegoś, co wcześniej działało. Wykonuje się je po każdej istotnej zmianie, zwykle jako stały zestaw testów obejmujący najważniejsze funkcje systemu.
Analityk biznesowy ma z regresją do czynienia przy każdej zmianie w działającym systemie: analiza wpływu zmiany (impact analysis) wskazuje, które obszary trzeba objąć testami. To też argument w rozmowach o priorytetach - biznes często nie rozumie, czemu „mała zmiana" wymaga dwóch dni testów. Wymaga, bo system to sieć powiązań, nie zbiór niezależnych funkcji.
Przykład z MediFlow: dodanie teleporad do modułu rezerwacji. Nowa funkcja działała świetnie. Regresja wykryła jednak, że filtr „tylko wizyty stacjonarne" w panelu recepcji przestał działać - nowy typ wizyty rozjechał logikę filtrowania, a recepcja w 12 przychodniach planuje na tym filtrze obłożenie gabinetów. Bez regresji błąd wyszedłby w poniedziałek rano, w najgorszym możliwym momencie.
Częsta pomyłka: rozumowanie „testowaliśmy nową funkcję, więc wszystko jest sprawdzone". Regresja dotyczy właśnie starych funkcji, których nikt świadomie nie ruszał. Druga sprawa: zakres regresji rośnie z każdym wydaniem i po roku ręczne przejście wszystkiego staje się niewykonalne - dlatego regresję automatyzuje się w pierwszej kolejności. Jeśli zespół mówi, że „nie ma czasu na regresję", to znaczy, że czas znajdzie się później. Na produkcji.