Jak skróciliśmy regresję z 3 dni do 42 minut

Bałagan w Sosnowcu: 148 scenariuszy i 3 dni czekania

Nasz klient to średniej wielkości firma spedycyjna z siedzibą pod Sosnowcem, która zarządza flotą 83 pojazdów ciężarowych. Ich głównym narzędziem pracy jest autorski system do rezerwacji frachtów, który przez ostatnie 4 lata urósł do sporych rozmiarów. Problem zaczął się, gdy każda mała zmiana w kodzie wymagała ręcznego sprawdzenia 148 scenariuszy testowych. Zajmowało to 6 osobom blisko trzy pełne dni robocze. Deweloperzy kończyli pracę w piątek, a raport z testów dostawali dopiero w środę po południu. To była czysta strata czasu, bo zespół programistyczny nie mógł ruszyć z nowymi zadaniami, czekając na zielone światło od działu jakości.

W praktyce wyglądało to tak, że błędy wykryte w poniedziałek były naprawiane dopiero w czwartek, co przesuwało wdrożenie na kolejny tydzień. Szczerze: testy manualne to dziś strata czasu w takim modelu. Firma traciła około 3200 euro miesięcznie na samym 'pustym' czasie pracy, kiedy programiści przełączali się między kontekstami. System zamiast pomagać w biznesie, stawał się wąskim gardłem. Właściciel firmy widział, że konkurencja szybciej wprowadza nowe funkcje, a jego zespół utknął w procedurach z 2018 roku. Musieliśmy wejść tam z konkretnym planem, bez zbędnych prezentacji i obiecywania cudów.

Kiedy pierwszy raz zobaczyliśmy ich arkusze Excel, złapaliśmy się za głowy. Niektóre testy polegały na sprawdzaniu, czy przycisk 'Wyloguj' ma odpowiedni odcień niebieskiego. W logistyce, gdzie liczy się każda minuta podstawienia auta pod rampę, takie detale nie powinny blokować wydania nowej wersji systemu. Skupiliśmy się na tym, co najważniejsze dla portfela klienta. Ustawiliśmy procesy, które działają same, eliminując z kolejki zadania, które deweloperzy mogą sprawdzić automatycznie w kilka sekund. Naszym celem było skrócenie całego cyklu tak, aby wydawanie kodu w każdą środę o 14:00 przestało być marzeniem, a stało się rutyną.

Kod musi zarabiać, a nie sypać błędami w arkuszu Excela u testera.

Cięcie zbędnego tłuszczu: 37 kluczowych ścieżek

Zaczęliśmy od brutalnej selekcji. Z 148 scenariuszy wybraliśmy 37, które realnie decydują o tym, czy firma zarabia pieniądze. Resztę uznaliśmy za szum, który tylko odwraca uwagę. Skupiliśmy się na procesie dodawania zlecenia, weryfikacji dokumentów przewozowych i systemie płatności dla podwykonawców. Pozostałe 111 przypadków testowych to były błędy wizualne lub rzadko używane funkcje, które mogły poczekać na luźniejszy dzień. To jest właśnie samo mięso naszej pracy: odróżnienie tego, co ważne, od tego, co tylko ładnie wygląda w raportach dla zarządu.

Wdrożenie automatyzacji podzieliliśmy na etapy. Pierwsze 12 dni poświęciliśmy na przygotowanie środowiska stabilnego jak stół w warsztacie. Wykorzystaliśmy narzędzie Playwright, bo działa stabilnie na różnych przeglądarkach i nie sypie błędami bez powodu. Napisaliśmy skrypty, które symulują pracę spedytora — od zalogowania, przez znalezienie wolnego auta, aż po wygenerowanie faktury PDF. Każdy test musiał być powtarzalny. Jeśli skrypt wywalał się raz na dziesięć prób z powodu sieci, poprawialiśmy go do skutku. Nie ma nic gorszego niż 'fałszywe błędy', które budują brak zaufania zespołu do automatyzacji.

Zamiast budować wielką infrastrukturę, postawiliśmy na proste kontenery Docker. Dzięki temu testy mogą odpalać się jednocześnie na 4 wirtualnych maszynach. To, co wcześniej człowiek klikał przez godzinę, automat robi w 3 minuty i 12 sekund. Najważniejsze było jednak to, żeby deweloperzy widzieli wynik testów od razu po wrzuceniu kodu do repozytorium. Skróciliśmy dystans między błędem a jego naprawą z 72 godzin do mniej niż godziny. To zmieniło całkowicie dynamikę pracy w biurze — zniknęło napięcie związane z oczekiwaniem na werdykt od testerów manualnych.

Automatyzacja CI/CD: Wynik 42 minuty

Finał prac nastąpił w 19. dniu współpracy. Cała paczka testów regresji, która wcześniej paraliżowała firmę na 3 dni, zaczęła kończyć się w dokładnie 42 minuty. To nie był wynik z kosmosu, tylko efekt wyrzucenia śmieci i równoległego odpalania skryptów. Deweloperzy dostali prosty komunikat na Slacku: 'Regresja przeszła pomyślnie, możesz wdrażać'. Bez zbędnych spotkań i potwierdzania wszystkiego u szefa działu QA. Procesy zaczęły działać same, a testerzy manualni mogli w końcu zająć się szukaniem trudnych błędów logicznych zamiast po raz tysięczny klikać w ten sam formularz.

Podczas wdrożenia napotkaliśmy jeden problem — baza danych testowych nie nadążała z czyszczeniem rekordów. Rozwiązaliśmy to w 4 godziny, pisząc prosty skrypt resetujący stan bazy po każdym przejściu testów. Dzięki temu każdy test startuje z 'czystą kartą', co wyeliminowało 92% dziwnych błędów, które wcześniej nękały zespół. Hej, nikt nie powiedział, że będzie łatwo, ale szczerze: testy manualne to dziś strata czasu, jeśli chcesz mieć system, który nie sypie błędami przy każdej okazji. Teraz zespół z Sosnowca robi wdrożenia nawet w czwartki, bo wiedzą, że automat wyłapie każdą grubą wpadkę.

Koszty utrzymania tego rozwiązania to około 140 euro miesięcznie za serwery testowe. W porównaniu do 3200 euro strat, które generował stary model, oszczędność jest oczywista. Klient odzyskał blisko 3000 euro w skali miesiąca, które może teraz zainwestować w rozwój nowych funkcji dla swoich kierowców. Statystyki z października 2024 roku pokazują, że liczba błędów krytycznych na produkcji spadła o 67%. To najlepszy dowód na to, że dobra architektura QA to nie koszt, tylko inwestycja, która zwraca się błyskawicznie. Teraz każda środa o 14:00 to czas na spokojne wdrożenie nowej wersji.

Ustawiamy procesy, które działają same, gdy Ty śpisz.

Jak wdrożyć to u siebie? Trzy konkretne kroki

Jeśli Twoja regresja trwa dłużej niż 4 godziny, masz problem, który z każdym miesiącem będzie droższy. Pierwszym krokiem nie jest kupno drogiego narzędzia, ale wzięcie kartki papieru i wypisanie 15 najważniejszych funkcji Twojej aplikacji. Jeśli te 15 rzeczy działa, firma zarabia. Reszta to dodatki. Zacznij od automatyzacji tylko tych ścieżek. Nie próbuj pokryć 99.1% systemu testami od razu, bo utkniesz w pisaniu skryptów na pół roku. Metoda małych kroków i skupienie na 'samym mięsie' daje najlepsze efekty biznesowe w najkrótszym czasie.

Drugi krok to integracja testów z Twoim procesem budowania kodu. Testy muszą odpalać się same. Jeśli programista musi pamiętać o ich włączeniu, to znaczy, że system jest zły. Ustaw GitHub Actions lub GitLab CI tak, żeby po każdym pushu maszyna sprawdzała bazowe funkcje. To daje deweloperom pewność siebie. Wiedzą, że jeśli coś zepsują, dowiedzą się o tym za 5 minut, a nie za 5 dni. To skraca czas nauki i sprawia, że nowi pracownicy szybciej stają się efektywni. W TyeVals widzieliśmy to już w 47 różnych projektach IT.

Trzeci krok to higiena danych. Testy muszą mieć własne, stabilne środowisko. Nie puszczaj automatów na bazie produkcyjnej ani na rozgrzebanej bazie deweloperskiej. Stwórz osobną kopię, którą można łatwo przywrócić do stanu początkowego. To klucz do tego, żeby Twoja regresja trwała 42 minuty, a nie 3 dni. Jeśli potrzebujesz wsparcia, żeby to poukładać, po prostu daj znać. Nie robimy długich audytów, tylko wchodzimy, sprawdzamy co nie działa i ustawiamy procesy, które po prostu zarabiają na siebie.