Testy regresyjne: co to jest, rodzaje, kiedy je uruchamiać i jak skrócić regresję z dni do godzin

Czas czytania: około 13 minut

Nowa funkcja przeszła wszystkie testy, wdrożenie poszło gładko, a godzinę później dział obsługi klienta zgłasza, że nie działa płatność kartą, która od roku nie sprawiała problemów. Nikt jej nie ruszał. Ruszono moduł rabatów, który dzieli z płatnością jedną funkcję przeliczania kwot. To jest regresja: zmiana w jednym miejscu psuje coś w innym, a testy regresyjne istnieją po to, żeby złapać ją przed wydaniem, nie po nim.

W tym tekście wyjaśniamy, czym są testy regresyjne według ISTQB, czym różnią się od retestów, jakie mają rodzaje i kiedy je uruchamiać, jak wybrać ich zakres, kiedy automatyzować, jak wpiąć je w CI/CD i jak mierzyć, czy działają. Pokazujemy też na liczbach z projektu dla klienta z e-commerce, jak skrócić regresję z pięciu dni do dziesięciu godzin. Piszemy dla testerów, automatyzujących i liderów, którzy decydują, ile regresji zmieści się przed piątkowym wydaniem.

Czym są testy regresyjne?

Testy regresyjne to testowanie wcześniej przetestowanego programu po modyfikacji, w celu upewnienia się, że w wyniku zmian nie powstały ani nie ujawniły się defekty w niezmienionych obszarach oprogramowania; wykonuje się je po każdej zmianie kodu lub środowiska.

Tak brzmi definicja ze słownika ISTQB. Słowo regresja oznacza cofnięcie się do gorszego stanu: funkcja, która działała, przestaje działać, choć nikt jej nie dotykał. Dzieje się tak, bo w oprogramowaniu moduły dzielą kod, dane i założenia. Zmiana formatu daty w jednym miejscu psuje raport w drugim, poprawka w funkcji zaokrąglania kwot zmienia wynik w trzech innych, aktualizacja biblioteki zmienia zachowanie komponentu, na którym opiera się pół systemu.

Testy regresyjne nie szukają błędów w nowej funkcji, od tego są testy zmian. Szukają skutków ubocznych zmiany w tym, co już istniało. Dlatego zestaw regresyjny składa się z testów, które już raz przeszły, i jest uruchamiany wielokrotnie, przy każdej kolejnej wersji. To właśnie powtarzalność odróżnia regresję od reszty testowania i to ona decyduje o wszystkim, co niżej: o rodzajach, zakresie, automatyzacji i koszcie.

Testy regresyjne, testy regresji czy testowanie regresywne: która nazwa jest poprawna?

Wszystkie trzy nazwy oznaczają to samo, czyli angielskie regression testing; od 2019 roku polski słownik ISTQB używa formy „testowanie regresji”, a „testy regresyjne” i „testy regresywne” to starsze tłumaczenia, nadal powszechne w ogłoszeniach, dokumentacji i mowie zespołów.

Zmiana tłumaczenia wzięła się z troski o język: „testy regresywne” mogły sugerować, że to testy powodują regres. W praktyce projektowej nikt nie ma z tym problemu, a w wyszukiwarce forma „testy regresyjne” jest wpisywana najczęściej. W tym tekście używamy więc „testy regresyjne” i „regresja” zamiennie z „testowaniem regresji”, bo chodzi o jedno pojęcie. Jeżeli piszecie dokumentację testową dla klienta, który trzyma się słownika ISTQB, użyjcie „testowania regresji” i dodajcie w słowniczku pozostałe formy, żeby nikt nie szukał różnicy, której nie ma.

Czym różnią się testy regresyjne od testów potwierdzających?

Test potwierdzający, czyli retest, sprawdza, czy konkretny zgłoszony błąd został naprawiony; test regresyjny sprawdza, czy naprawa tego błędu nie zepsuła czegoś innego. Pierwszy dotyczy jednego defektu, drugi całego otoczenia zmiany, i oba wykonuje się po każdej poprawce.

Słownik ISTQB definiuje test potwierdzający jako testowanie wykonywane po naprawie defektu, żeby potwierdzić, że został usunięty. Kolejność w praktyce jest zawsze taka sama: najpierw retest, potem regresja. Nie ma sensu uruchamiać regresji obszaru, w którym poprawka nie zadziałała, o czym piszemy szerzej przy okazji smoke testu i sanity testu, dwóch filtrów, które poprzedzają regresję, ale jej nie zastępują.

Dlaczego regresja jest potrzebna, skoro zmiana była mała?

Regresja jest potrzebna, bo „mała zmiana” mówi o liczbie zmienionych linii, a nie o liczbie miejsc, które od nich zależą; jedna funkcja pomocnicza może być wywoływana z dwudziestu modułów i nikt w zespole nie pamięta wszystkich dwudziestu.

Sylabus ISTQB Foundation Level 4.0 ujmuje to wprost: zmiana wprowadzona w jednej części kodu może przypadkowo wpłynąć na zachowanie innych części tego samego modułu, innych modułów tego samego systemu, a nawet innych systemów. Do tego dochodzą zmiany środowiska: nowa wersja bazy danych, systemu operacyjnego, przeglądarki, biblioteki. Żadna z nich nie zmienia Waszego kodu, a każda może zmienić jego zachowanie.

Koszt regresji trzeba zestawić z kosztem jej braku. Błąd regresji znaleziony przed wydaniem to godzina pracy programisty. Ten sam błąd na produkcji to przerwane płatności, zgłoszenia do obsługi klienta, wycofanie wersji i tydzień szukania, która z trzydziestu zmian w wydaniu zawiniła. Zespoły, które skarżą się na drogą regresję, zwykle nigdy nie policzyły, ile kosztuje ich jedna awaria na produkcji w sezonie.

Liczby z projektu dla Argos, sklepu internetowego, potwierdzone przez klienta. Ten sam mechanizm opisujemy od strony budżetu w tekście o długu technologicznym: bez zaufania do regresji zespół nie odważy się ruszyć starego kodu, więc dług nie maleje, tylko zamraża się w miejscu.

Jakie są rodzaje testów regresyjnych?

W praktyce wyróżnia się regresję pełną, selektywną, priorytetyzowaną i korekcyjną, a osobno regresję na poziomie jednostkowym, integracyjnym i systemowym; różnią się zakresem i kosztem, a wybór zależy od wielkości zmiany, ryzyka i czasu do wydania.

Regresja dzieje się też na każdym poziomie testowania: testy jednostkowe uruchamiane przez programistów przy każdym commicie, testy API na środowisku integracyjnym, testy interfejsu na środowisku zbliżonym do produkcji. O tym, jak rozłożyć ciężar między poziomami, piszemy w tekście o poziomach testowania, a miejsce regresji wśród innych typów testów porządkuje tekst o typach testów oprogramowania.

Kiedy uruchamiać testy regresyjne?

Testy regresyjne uruchamia się po każdej poprawce błędu, po dodaniu nowej funkcji, po refaktoryzacji, po zmianie środowiska lub zależności, przed każdym wydaniem oraz po wdrożeniu na produkcję w wersji skróconej; częstotliwość zależy od tego, ile z tego zestawu jest zautomatyzowane.

W zespołach pracujących w sprintach regresja jest ciągła: testy jednostkowe i API biegną przy każdej zmianie, testy interfejsu raz dziennie, pełna regresja przed wydaniem. Tak rozkłada to piramida testów. To dokładnie kierunek, który opisujemy w tekście o shift left testing: im wcześniej i częściej biegnie regresja, tym mniej kosztuje każde jej uruchomienie.

Jak wybrać zakres regresji: analiza wpływu i ryzyka

Zakres regresji wybiera się analizą wpływu (co zależy od zmienionego kodu, danych i interfejsów) połączoną z analizą ryzyka (co boli najbardziej, gdy przestanie działać); wynikiem jest lista testów uporządkowana wagą, a nie decyzja „wszystko albo nic”.

Analiza wpływu odpowiada na pytanie techniczne: które moduły wywołują zmieniony kod, które tabele czytają zmienione dane, które systemy korzystają ze zmienionego interfejsu. Dobrym źródłem jest historia zmian, mapa zależności i programista, który zmianę wprowadził. Analiza ryzyka odpowiada na pytanie biznesowe: które z tych obszarów generują przychód, dotyczą pieniędzy lub danych osobowych, mają największy ruch albo historię awarii. Przecięcie obu list to jądro regresji, a reszta ustawia się za nim.

Plan regresji dla wydania 3.42 (zmiana: nowy silnik rabatów)

Poziom 1, zawsze, około 40 min automatycznie:
  logowanie, koszyk, naliczanie rabatu, płatność kartą, BLIK, potwierdzenie zamówienia

Poziom 2, obszary zależne od zmiany, około 2 h automatycznie + 1 h ręcznie:
  zwroty i korekty faktur (dzielą funkcję przeliczania kwot), raport sprzedaży, kody promocyjne,
  konto klienta: historia zamówień z rabatem

Poziom 3, reszta zestawu, tylko przy pełnej regresji przed dużym wydaniem:
  wyszukiwarka, filtry, newsletter, panel administratora, eksport danych

Wyłączone z tej regresji z uzasadnieniem: moduł magazynu (brak zależności od kwot, potwierdzone z zespołem)

Taki plan ma trzy zalety: da się go wykonać w dostępnym czasie, każdy wie, co zostało sprawdzone, a to, co pominięto, jest pominięte świadomie i z podpisem. Ramy dla takich decyzji ustala plan testów, w którym zakres regresji dla różnych typów wydań warto zapisać raz, zamiast negocjować go przed każdym.

Testy regresyjne manualne czy automatyczne?

Regresję powtarzalnych, stabilnych ścieżek automatyzujcie, a ręcznie zostawcie eksplorację nowych obszarów, sprawdzenie wyglądu i scenariusze, które zmieniają się co sprint; zestaw regresyjny uruchamiany ręcznie przy każdym wydaniu to najdroższa rzecz, jaką zespół QA może robić.

Automatyzacja regresji nie polega na nagraniu klikania. Najtańsze i najstabilniejsze są testy na poziomie API i integracji, dopiero nad nimi cienka warstwa testów interfejsu dla ścieżek, które użytkownik naprawdę przechodzi. Kiedy automatyzacja się opłaca, a kiedy nie, rozkładamy w tekstach o testowaniu manualnym i automatycznym oraz zaletach i wadach automatyzacji.

Jak skrócić regresję z pięciu dni do dziesięciu godzin?

Regresję skraca się w czterech ruchach: zmierzenie, ile naprawdę trwa i co w niej jest, wycięcie testów bez wartości, przeniesienie sprawdzania logiki z interfejsu na API oraz uruchamianie zestawu w pipeline przy każdej zmianie zamiast raz przed wydaniem; tak u naszego klienta z e-commerce pięć dni zmieniło się w dziesięć godzin.

1. Zmierzcie stan wyjściowy. Ile trwa pełna regresja, ile osób ją wykonuje, ile testów zawiera, ile z nich znalazło jakikolwiek błąd w ostatnim roku. W Argos ta pierwsza tabela była najbardziej otrzeźwiającym dokumentem projektu.
2. Wytnijcie balast. Testy duplikujące się, testy funkcji, których już nie ma, testy, które nie znalazły nic od dwóch lat i nie chronią niczego ważnego. Zestaw regresyjny rośnie sam, a kurczy się tylko decyzją.
3. Zejdźcie z interfejsu na API. Większość logiki biznesowej da się sprawdzić żądaniem do API w ułamku sekundy, zamiast klikaniem przez pięć ekranów w minutę. Na interfejsie zostają wyłącznie ścieżki krytyczne, które użytkownik widzi.
4. Wepnijcie regresję w pipeline. Testy jednostkowe i API przy każdym commicie, testy interfejsu raz dziennie, pełny zestaw przed wydaniem. Regresja przestaje być wydarzeniem, a staje się tłem.
5. Uporządkujcie dane i środowiska. Połowa czerwonych wyników regresji to nie błędy w kodzie, tylko brak danych testowych, zajęte środowisko albo niedostępny system zewnętrzny. Bez tej warstwy pipeline będzie czerwony z powodów, które nikogo nie interesują.

W Argos efektem było skrócenie regresji przed wydaniem z pięciu dni do dziesięciu godzin, 46 procent mniej błędów krytycznych na produkcji i 72 procent mniej awarii w szczycie sezonu. Nie dlatego, że testów było mniej, tylko dlatego, że były we właściwych miejscach i biegły przy każdej zmianie. Ten ruch od strony architektury testów opisujemy w tekście o testach integracyjnych, a wdrażamy go w ramach automatyzacji testów i usługi testów regresyjnych dla firm.

Jak wpiąć testy regresyjne w CI/CD i co zrobić z testami niestabilnymi?

W CI/CD regresja biegnie warstwami: szybkie testy jednostkowe i API blokują scalenie zmiany, testy interfejsu krytycznych ścieżek biegną po wdrożeniu na środowisko testowe, a pełny zestaw przed wydaniem; testy niestabilne trzeba izolować i naprawiać, a nie uruchamiać ponownie do skutku.

Test niestabilny, czyli flaky, to taki, który raz przechodzi, raz nie, bez zmiany w kodzie. Google w tekście Flaky Tests at Google and How We Mitigate Them opisało, że około 1,5 procent uruchomień testów w ich systemach dawało wynik niestabilny, i że to wystarczy, żeby zespoły przestały ufać czerwonym wynikom. Martin Fowler w Eradicating Non-Determinism in Tests nazywa takie testy zarazą: kilka niestabilnych testów sprawia, że cały zestaw traci wiarygodność.

• Kwarantanna zamiast ponawiania. Test, który migocze, trafia do osobnej grupy, nie blokuje pipeline i ma właściciela z terminem naprawy. Automatyczne ponawianie do skutku ukrywa problem i wydłuża regresję.
• Przyczyny do sprawdzenia w kolejności: zależność od czasu i kolejności testów, współdzielone dane testowe, oczekiwanie na element interfejsu bez warunku, prawdziwe systemy zewnętrzne zamiast atrap, zbyt małe środowisko.
• Regresja jako bramka, nie raport. Czerwona regresja zatrzymuje wdrożenie. Jeśli zespół uczy się ją omijać „bo to na pewno flaky”, regresja przestaje istnieć, choć formalnie biegnie.
• Czas uruchomienia ma limit. Zestaw przy commicie w kilka minut, dzienny w godzinę, pełny w noc. Zestaw, który wyrasta ponad limit, dostaje przegląd, nie większy serwer.

Budowę takich potoków prowadzimy w ramach budowy procesów CI/CD, a wymagania regulacyjne wobec regresji w sektorze finansowym, w tym częstotliwość testów, opisujemy w tekście o rozporządzeniu DORA.

Jakie są najczęstsze błędy w testach regresyjnych?

Najczęstsze błędy to regresja „wszystko albo nic”, zestaw, który tylko rośnie, regresja bez retestu, testy niestabilne ponawiane do skutku, regresja wyłącznie na interfejsie oraz brak zapisu, co zostało sprawdzone, a co świadomie pominięte.

1. Wszystko albo nic. Pełna regresja przy każdej poprawce kończy się tym, że przy presji terminu nie biegnie żadna. Zakres warstwowy z poziomu 1 uruchamianym zawsze rozwiązuje ten problem.
2. Zestaw bez sprzątania. Każdy sprint dodaje testy, żaden nie usuwa. Po dwóch latach połowa zestawu sprawdza funkcje, których nie ma, albo duplikuje inne testy.
3. Regresja bez retestu. Uruchomienie zestawu na obszarze, w którym poprawka nie zadziałała, to godziny stracone na sprawdzanie skutków ubocznych zmiany, która nie działa.
4. Ponawianie zamiast naprawy. Test uruchamiany trzy razy do skutku nie jest testem. Jest losowaniem.
5. Tylko interfejs. Regresja klikana albo nagrana przez interfejs jest wolna, krucha i psuje się przy każdej zmianie wyglądu. Logika należy do API.
6. Brak śladu. Po wydaniu nikt nie umie powiedzieć, co było w regresji. Przy awarii nie da się ustalić, czy luka była w zakresie, czy w wykonaniu.
7. Regresja tylko przed wydaniem. Błąd wprowadzony w pierwszym dniu sprintu czeka dwa tygodnie na wykrycie, a wtedy kosztuje wielokrotnie więcej.

Jak mierzyć, czy regresja działa?

Skuteczność regresji mierzy się czterema liczbami: czasem pełnego przebiegu, pokryciem krytycznych ścieżek biznesowych, liczbą błędów regresji, które mimo wszystko trafiły na produkcję, oraz odsetkiem wyników niestabilnych; jeśli któraś nie jest liczona, nie wiadomo, czy regresja działa, czy tylko biegnie.

Te miary warto pokazać nie tylko zespołowi QA, ale i osobom, które decydują o budżecie na automatyzację. Regresja z pięciu dni na dziesięć godzin to nie „lepsza jakość”, tylko konkretna liczba dni odzyskanych w każdym wydaniu, którą da się przeliczyć na pieniądze. Kompetencje w tym obszarze budujemy na szkoleniu Automatyzacja testów Selenium WebDriver oraz Wprowadzenie do testowania API Postman, a wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o testy regresyjne

Co to są testy regresyjne?

Testy regresyjne to ponowne wykonanie testów na wcześniej przetestowanych, niezmienionych częściach systemu po wprowadzeniu zmiany w kodzie lub środowisku. Sprawdzają, czy zmiana nie zepsuła tego, co wcześniej działało. Nie testują nowej funkcji, tylko skutki uboczne jej dodania.

Czym różnią się testy regresyjne od retestu?

Retest, czyli test potwierdzający, sprawdza, czy konkretny zgłoszony błąd został naprawiony. Test regresyjny sprawdza, czy ta naprawa nie zepsuła innych funkcji. Kolejność jest zawsze taka sama: najpierw retest, potem regresja.

Kiedy wykonuje się testy regresyjne?

Po każdej poprawce błędu, po dodaniu nowej funkcji, po refaktoryzacji, po zmianie środowiska lub bibliotek, przed każdym wydaniem oraz w wersji skróconej po wdrożeniu na produkcję. W CI/CD testy jednostkowe i API biegną przy każdej zmianie kodu.

Czy testy regresyjne trzeba automatyzować?

Nie trzeba, ale to najbardziej opłacalny obszar automatyzacji, bo ten sam zestaw powtarza się przy każdej wersji. Automatyzujcie powtarzalne, stabilne ścieżki o dużej wadze biznesowej, najlepiej na poziomie API. Ręcznie zostawcie eksplorację i obszary, które zmieniają się co sprint.

Jak wybrać zakres testów regresyjnych?

Analizą wpływu, czyli sprawdzeniem, co zależy od zmienionego kodu, danych i interfejsów, połączoną z analizą ryzyka, czyli oceną, co boli najbardziej, gdy przestanie działać. Wynikiem jest zestaw warstwowy: poziom 1 uruchamiany zawsze, poziom 2 dla obszarów zależnych od zmiany, poziom 3 przy pełnej regresji.

Ile powinna trwać regresja?

Krócej niż okno wydania, z zapasem na naprawy. Zestaw przy commicie w kilka minut, dzienny w godzinę, pełny w noc. U naszego klienta z e-commerce regresja przed wydaniem skróciła się z pięciu dni do dziesięciu godzin po przeniesieniu logiki na testy API i wpięciu zestawu w pipeline.

Testy regresyjne czy testowanie regresji: która nazwa jest poprawna?

Obie oznaczają to samo, czyli regression testing. Polski słownik ISTQB od 2019 roku używa formy „testowanie regresji”, a „testy regresyjne” i „testy regresywne” to starsze tłumaczenia, nadal powszechne w zespołach i ogłoszeniach.

Co zrobić z testami niestabilnymi w regresji?

Odizolować je w osobnej grupie, która nie blokuje pipeline, przypisać właściciela i termin naprawy, a przyczyn szukać w zależności od czasu, współdzielonych danych, oczekiwaniu na elementy interfejsu bez warunku i prawdziwych systemach zewnętrznych. Automatyczne ponawianie do skutku ukrywa problem.

Powiązane na blogu Quality Island

• Smoke test: co to jest, kiedy go uruchamiać i czym różni się od sanity testu
• Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać krok po kroku
• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku
• Typy testów oprogramowania
• Dług technologiczny pożera nawet 40% budżetu IT: gdzie w tym jest testowanie
• Testowanie manualne i automatyczne: jakie są różnice i kiedy wybrać każde podejście

Pełna lista źródeł

• ISTQB Glossary, hasła regression testing, confirmation testing i regression-averse testing
• ISTQB, sylabus Certified Tester Foundation Level v4.0
• Google Testing Blog, Flaky Tests at Google and How We Mitigate Them (2016)
• Martin Fowler, Eradicating Non-Determinism in Tests
• Wikipedia, Regression testing
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta