Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos

Jeśli zapytacie dziesięciu Head of QA, co najbardziej hamuje wydawanie nowych wersji, ośmiu odpowie to samo: regresja. Nie brak testerów, nie zła architektura, tylko ten jeden etap tuż przed release’em, w którym zespół musi ręcznie przeklikać dziesiątki scenariuszy, żeby upewnić się, że nowa funkcja niczego nie zepsuła. To pytanie o efekt jest w rozmowach o testach najczęstsze i najtrudniejsze: skąd mamy wiedzieć, ile realnie zyskamy, zanim zapłacimy za automatyzację? Ten artykuł odpowiada na nie liczbami z jednego, konkretnego wdrożenia, nie ogólnikiem o „przyspieszeniu procesów”.

Klient z branży e-commerce, w tym artykule pod nazwą Argos, zgłosił się z problemem: testy regresyjne przed każdym większym wydaniem zajmowały pięć dni roboczych zespołu testowego. Po wdrożeniu automatyzacji testów i uporządkowaniu procesów QA ten sam zakres testów regresyjnych zszedł do dziesięciu godzin. Nie jest to obietnica z folderu ofertowego, tylko wynik potwierdzony przez klienta, razem z trzema innymi liczbami, które omawiamy niżej.

Dlaczego regresja rośnie szybciej niż zespół QA

Regresja nie jest stałym kosztem. Rośnie z każdą nową funkcją, bo każda z nich dokłada kolejne ścieżki, które trzeba sprawdzić przed każdym kolejnym wydaniem, nie tylko przy swojej premierze. Zespół, który rok temu regresję robił w jeden dzień, dziś potrzebuje na to samo zadanie trzech albo pięciu, mimo że nikogo nie ubyło. To matematyka, nie zaniedbanie: liczba ścieżek do sprawdzenia rośnie z każdym sprintem, a liczba osób, które mogą je ręcznie sprawdzić, zostaje na tym samym poziomie.

W praktyce ten problem ujawnia się w trzech miejscach naraz. Po pierwsze, w terminie wydania: jeśli regresja zajmuje pięć dni, a firma chce wydawać co tydzień, testerzy zaczynają regresję, zanim development w ogóle skończy pracę nad wersją, co oznacza testowanie kodu, który się jeszcze zmienia. Po drugie, w jakości samej regresji: pod presją czasu zespół skraca zakres, testując tylko to, co „na pewno” mogło się zepsuć, a to właśnie w tych pominiętych miejscach chowają się defekty produkcyjne. Po trzecie, w kosztach: pięć dni pracy zespołu testowego przed każdym wydaniem to nie jest jednorazowy wydatek, tylko powtarzalny koszt, który mnoży się razy liczba wydań w roku.

Jeśli Wasza regresja zajmuje dni, nie jesteście wyjątkiem, tylko statystyką. Według State of Quality Report 2025 od Katalon, opartego na odpowiedziach 1 400 specjalistów QA, 82 procent zespołów wciąż testuje ręcznie każdego dnia, a 55 procent badanych wskazuje brak czasu na dokładne testy jako główny problem jakości. World Quality Report 2024-25 od Capgemini i OpenText dorzuca liczbę, która dobrze tłumaczy, dlaczego u Was może iść wolniej niż w prezentacjach dostawców narzędzi: 64 procent organizacji wskazuje architekturę legacy jako główną przeszkodę w automatyzacji testów. Jest też obserwacja mniej naukowa: po setnym ręcznym przejściu przez checkout tester zna numer testowej karty płatniczej lepiej niż numer do własnej mamy, i to bywa jedyny trwały efekt takiej regresji.

Case Argos: co zmieniło się w projekcie

Zakres prac przy Argosie obejmował dwie rzeczy naraz, nie jedną. Sama automatyzacja testów bez uporządkowania procesu QA daje mniej, niż się wydaje, bo szybko wykonany chaotyczny test wciąż jest chaotycznym testem. Dlatego obok budowy testów automatycznych UI i API dla kluczowych ścieżek, w tym checkoutu i płatności, uporządkowaliśmy też, kto decyduje o starcie regresji, w jakiej kolejności testy się uruchamiają i co blokuje wydanie, a co jest tylko ostrzeżeniem do przejrzenia po fakcie.

Efekt widać w czterech miejscach, i każdy z nich odpowiada na inne pytanie decydenta. Skrócenie regresji z pięciu dni do dziesięciu godzin odpowiada na pytanie o czas: ile szybciej można wydawać. Spadek awarii w okresach szczytowych o 72 procent i błędów krytycznych na produkcji o 46 procent odpowiada na pytanie o ryzyko: czy szybsze wydawanie nie oznacza więcej awarii, tylko odwrotnie, mniej. Wzrost konwersji o 12 procent jest tu najważniejszą liczbą dla działu finansowego, bo pokazuje, że stabilność checkoutu i płatności przekłada się wprost na przychód, nie tylko na spokój zespołu technicznego.

Argument, który pada zaraz po pytaniu o efekt: „u nas system jest inny”

Zanim decydent zapyta o efekt, często pada druga obawa, cichsza, ale równie blokująca: że wdrożenie zewnętrznego zespołu do specyficznego, rozbudowanego systemu zajmie miesiące samego wdrażania się, zanim ktokolwiek zacznie realnie testować. To nie jest obawa o kompetencje, tylko o tarcie na wejściu, i akurat na to odpowiada nie jeden projekt, tylko skala wszystkich razem.

Quality Island ma za sobą ponad 150 zrealizowanych projektów i portfolio, które celowo nie jest jednorodne: e-commerce jak Argos, motoryzacja i wynajem samochodów jak Autono, systemy medyczne jak ChaosGears, bankowość jak PKO BP. Każdy z tych systemów miał swoją specyfikę, własną architekturę i własne ograniczenia, a mimo to nasz zespół napisał w nich łącznie ponad 450 000 testów automatycznych. Ta liczba nie jest ciekawostką, tylko dowodem, że „nasz system jest specyficzny” rzadko oznacza „niemożliwy do zautomatyzowania”, tylko „wymaga zespołu, który już widział wystarczająco dużo różnych systemów, żeby nie zaczynać metody od zera”.

W praktyce onboarding do konkretnego systemu klienta zawsze zajmuje trochę czasu, tego nie da się obiecać inaczej. Różnica polega na tym, co się dzieje w tym czasie: zespół, który robił to po raz pierwszy, uczy się metody i systemu naraz, a zespół z ponad 150 projektami za sobą uczy się wyłącznie systemu, bo metodę ma już dopracowaną. To właśnie skraca tarcie na wejściu, nie obietnica, że system klienta „wcale nie jest taki specyficzny”.

Jakie testy regresyjne automatyzować najpierw

Błąd, który najczęściej wydłuża drogę do wyniku podobnego do Argosa, to automatyzowanie po kolei, ekran po ekranie, zamiast według ryzyka. Z naszego doświadczenia z audytów i szkoleń wynika, że to podejście jest domyślne w większości zespołów, nie dlatego, że komuś brakuje kompetencji, tylko dlatego, że nikt wcześniej nie policzył kosztu awarii pojedynczej ścieżki. Cztery pytania porządkują tę decyzję szybciej niż jakakolwiek lista narzędzi.

• Co kosztuje najwięcej, jeśli się zepsuje? Checkout i płatności prawie zawsze wygrywają ten test, bo awaria tam oznacza wprost utraconą sprzedaż, nie tylko zgłoszenie od użytkownika.
• Jak często ta ścieżka jest testowana w regresji? Scenariusz sprawdzany przy każdym wydaniu zwraca koszt automatyzacji znacznie szybciej niż ten, który testuje się raz na kwartał.
• Jak stabilny jest dziś ten fragment interfejsu? Automatyzacja ekranu, który za miesiąc przechodzi redesign, to praca do wyrzucenia. Lepiej poczekać albo zacząć od warstwy API, która zmienia się rzadziej niż UI.
• Ile kosztuje błąd fałszywie pozytywny? Test, który failuje bez realnego powodu częściej niż raz na kilka uruchomień, kosztuje zaufanie zespołu szybciej, niż warty jest jego pierwotny cel.

W Argosie te cztery pytania wskazały jednoznacznie na checkout i płatności jako pierwszy cel, nie na całą aplikację naraz. To jedna z przyczyn, dla których wynik pojawił się w miesiącach, nie w roku: budżet poszedł tam, gdzie ryzyko było największe, a nie tam, gdzie automatyzacja była najłatwiejsza technicznie. Warstwa API zwykle wygrywa też z warstwą UI jako pierwszy krok, bo zmienia się rzadziej i testy oparte na niej rzadziej się psują przy kosmetycznych zmianach interfejsu, o czym pisaliśmy szerzej przy okazji wzorców projektowych w Selenium.

Co faktycznie skraca regresję, nie tylko „więcej ludzi”

Najczęstsza pierwsza reakcja na rosnącą regresję to dołożenie testerów do zespołu. To działa liniowo, jeśli w ogóle działa: dwa razy więcej ludzi robi tę samą pracę w połowie czasu, ale nie krócej, bo liczba scenariuszy rośnie szybciej niż budżet na zatrudnienie. Automatyzacja skraca regresję nieliniowo, bo raz napisany test wykonuje się w minutach, niezależnie od tego, ile razy go uruchomicie w tym miesiącu.

Wniosek z tej tabeli nie brzmi „zautomatyzujcie wszystko”. Regresja wizualna i ocena sensowności doświadczenia użytkownika wciąż potrzebują człowieka, automatyzacja zabiera z jego grafiku powtarzalne sprawdzanie tego samego, żeby zostawić czas na to, czego maszyna nie oceni. W Argosie to właśnie ten podział zdecydował o wyniku: automatyzacja przejęła powtarzalną regresję funkcjonalną checkoutu i płatności, a testerzy skupili się na nowych funkcjach i przypadkach brzegowych, które faktycznie wymagają osądu.

Jak wygląda u nas droga od pięciu dni do dziesięciu godzin

Źródło: metodyka własna Quality Island, stosowana w projektach automatyzacji.

Krok czwarty jest tym, który najczęściej ginie w rozmowach o automatyzacji, a to on decyduje, czy skrócona regresja zostaje skrócona na stałe, czy wraca do punktu wyjścia po kilku miesiącach. Testy automatyczne bez utrzymania psują się po cichu, w naszych projektach widzimy to regularnie: interfejs się zmienia, selektor przestaje pasować, test zaczyna failować z powodów niezwiązanych z jakością produktu, a zespół, zmęczony fałszywymi alarmami, w końcu przestaje testy uruchamiać albo ignoruje ich wyniki. W tym momencie automatyzacja przestaje chronić przed regresją, mimo że formalnie wciąż istnieje w repozytorium. Dlatego stałe wsparcie automatyzacji nie jest opcjonalnym dodatkiem, tylko warunkiem, żeby wynik z case Argosa się utrzymał.

Ile to kosztuje i od czego zacząć

Skrócenie regresji rzadko zaczyna się od razu od pełnego wdrożenia. W doradztwie automatyzacja testów najpierw sprawdzamy, które scenariusze mają największy sens do zautomatyzowania w waszym konkretnym produkcie, zanim ktokolwiek napisze pierwszy test. Jeśli najbliższe wydanie nie może czekać na automatyzację, regresję przed nim wykonamy ręcznie w ramach usługi testy regresyjne.

Automatyzacja testów mobilnych jest w ofercie na tych samych zasadach, wyceniana indywidualnie po analizie. Jeśli w organizacji regresja jest dziś w większości ręczna, a proces wydawania w ogóle nie jest wpięty w CI/CD, sensowną kolejnością jest zacząć od budowy procesów CI/CD równolegle z pierwszymi testami, zamiast budować automatyzację, która i tak będzie uruchamiana ręcznie przez najbliższy rok.

Firmy z wieloma produktami albo zespołami testowymi, które potrzebują nie tylko automatyzacji, ale kogoś, kto ogarnie cały proces decyzji release, priorytetów i raportowania, częściej trafiają do modelu długofalowej współpracy QA niż do jednorazowego projektu. To rozróżnienie warto zrobić na starcie rozmowy, bo zmienia zarówno zakres, jak i sposób rozliczenia.

Co zrobić, jeśli u was regresja też zajmuje dni, nie godziny

Zanim zamówicie automatyzację, warto policzyć dwie liczby, które w Argosie były punktem wyjścia do rozmowy o zakresie. Pierwsza to realny czas regresji dziś, liczony nie w idealnych warunkach, tylko z ostatnich trzech wydań, łącznie z poprawkami po znalezionych błędach. Druga to liczba wydań, które planujecie w najbliższym roku: te same pięć dni regresji kosztuje zupełnie inaczej przy czterech wydaniach rocznie niż przy pięćdziesięciu dwóch. Te dwie liczby, zestawione razem, pokazują, czy automatyzacja ma się zwrócić w miesiącach, czy w latach, jeszcze zanim ktokolwiek napisze pierwszy test.

Warto przy tym pamiętać, że koszt złej jakości nie jest abstrakcją z prezentacji. Według raportu CISQ z 2022 roku zła jakość oprogramowania kosztowała samą gospodarkę Stanów Zjednoczonych co najmniej 2,41 biliona dolarów, a narosły dług techniczny ten sam raport CISQ wycenia na około 1,52 biliona dolarów. Wasza regresja jest małym wycinkiem tego rachunku, ale płacicie go przy każdym wydaniu, więc macie nad nim znacznie większą kontrolę niż nad resztą tej listy.

Po czym poznać, że automatyzacja regresji faktycznie działa

Wdrożenie automatyzacji bez ustalonych z góry mierników kończy się zwykle wrażeniem, że „chyba jest lepiej”, zamiast liczbą, którą można pokazać zarządowi. Trzy wskaźniki wystarczą, żeby ocenić wynik bez zgadywania, i wszystkie trzy dają się policzyć bez dodatkowych narzędzi poza tym, co firma już ma.

Pierwszy to czas regresji liczony od startu do zielonego wyniku, mierzony przy każdym wydaniu, nie raz na kwartał jako średnia z pamięci. Drugi to liczba defektów, które przeszły przez regresję i trafiły na produkcję, bo skrócenie czasu bez utrzymania jakości wykrywania nie jest sukcesem, tylko przesunięciem problemu na klientów. Trzeci to częstotliwość wydań: jeżeli regresja realnie się skróciła, a firma nadal wydaje raz na miesiąc z przyzwyczajenia, część wartości automatyzacji zostaje niewykorzystana. W Argosie wszystkie trzy wskaźniki poszły w tę samą stronę naraz, co jest rzadsze, niż się wydaje: zwykle firmy widzą poprawę jednego kosztem drugiego, na przykład szybszą regresję przy niezmienionej albo gorszej liczbie błędów, które przeszły dalej.

Powiązane na blogu Quality Island

• 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
• Testy akceptacyjne (UAT): co to jest, rodzaje, kryteria akceptacji i jak je przeprowadzić
• Automatyzacja testów Selenium WebDriver: wzorce projektowe, które zwiększają stabilność i skalowalność testów

Pogłębiona matryca decyzyjna, co realnie opłaca się automatyzować, na tych samych danych z case Argos: Automatyzacja testów: co się naprawdę opłaca automatyzować, a co nie na StrefieQA.

Pełna lista źródeł

• Katalon, State of Quality Report 2025 (ankieta 1 400 specjalistów QA), 2025, katalon.com. Stąd liczby o automatyzacji regresji (45 procent), codziennym testowaniu ręcznym (82 procent), braku czasu na testy (55 procent) i zwrocie z automatyzacji (36 i 21 procent)
• Capgemini i OpenText, World Quality Report 2024-25, 2024, capgemini.com. Stąd dana o architekturze legacy jako głównej przeszkodzie automatyzacji testów (64 procent organizacji)
• CISQ, The Cost of Poor Software Quality in the US, 2022, it-cisq.org. Stąd koszt złej jakości oprogramowania w USA (2,41 biliona dolarów) i wycena długu technicznego (1,52 biliona dolarów)
• Case study klienta Quality Island, e-commerce (Argos), wyniki potwierdzone przez klienta, 2026. Stąd wszystkie liczby wdrożenia: regresja z 5 dni do 10 godzin, minus 72 procent awarii w szczytach, minus 46 procent błędów krytycznych, plus 12 procent konwersji
• Cennik usług Quality Island, sierpień 2026. Stąd ceny usług automatyzacji w tabeli
• Metodyka i praktyka własna Quality Island z projektów automatyzacji testów