12 / Jakość, chmura i infrastruktura
Regresja sprawdzana przy każdej zmianie, nie raz na kwartał
Budujemy i utrzymujemy zestawy testów automatycznych, którym zespół ufa — działające w CI, z kosztem utrzymania policzonym z góry.
Ręczna regresja ma stałą cenę: kilka dni pracy zespołu przed każdym wydaniem i cichą zgodę na to, że przy pośpiechu sprawdzi się mniej. Im większy system, tym częściej ta cena jest płacona skracaniem zakresu — a błąd wychodzi u klienta.
Automatyzacja rozwiązuje to tylko wtedy, gdy testy są utrzymywane jak produkcyjny kod. Dlatego zaczynamy od tego, co warto automatyzować, a nie od narzędzia: krytyczne ścieżki i powtarzalna regresja idą do automatu, jednorazowe scenariusze zostają manualne. Zestaw pisany jest w Pythonie z PyTest, wersjonowany w Twoim repozytorium i uruchamiany w pipeline przy każdej zmianie — z raportem, który da się przeczytać bez tłumacza.
W środowiskach PwC, Roche i E.ON, w których pracował założyciel firmy, zestaw testów jest częścią wydania, a nie osobnym projektem obok — i dokładnie tak go tutaj traktujemy. Mówimy też wprost o granicy: jeśli utrzymanie testu kosztowałoby więcej, niż jest wart, nie proponujemy go.
Zakres usługi
Framework i pierwszy działający zestaw
Wychodzisz z tego etapu z testami, które faktycznie chodzą: struktura projektu testowego, konfiguracja środowisk, dane testowe i zestaw pokrywający ścieżki, na których firma zarabia. Bez heroicznego pokrycia „wszystkiego” — z pokryciem tego, co boli.
- Wybór podejścia i struktura projektu testowego
- Konfiguracja środowisk i danych testowych
- Zestaw smoke dla krytycznych ścieżek
- Czytelne raporty z wykonania
Testy API i integracji
Najtańsze testy w całym zestawie i zwykle najbardziej opłacalne: sprawdzają kontrakty między systemami, kody odpowiedzi, walidacje i scenariusze przechodzące przez kilka usług — bez kruchości typowej dla testów interfejsu.
- Testy kontraktów i endpointów REST
- Scenariusze przez kilka systemów
- Testy autoryzacji i walidacji danych wejściowych
Testy interfejsu i regresja wizualna
Testy UI tam, gdzie naprawdę są potrzebne — na ścieżkach zakupu, logowania i wypełniania formularzy. Piszemy je tak, żeby przetrwały zmianę layoutu: selektory oparte na rolach i danych, nie na kolejności elementów.
- Testy krytycznych ścieżek użytkownika
- Testy formularzy i walidacji
- Sprawdzanie w wielu przeglądarkach
Uruchomienie w CI/CD
Testy, których nikt nie musi pamiętać, żeby uruchomić. Podpinamy zestaw pod pipeline (GitHub Actions), ustawiamy bramki jakości dla pull requestów i nocne przebiegi pełnej regresji, a wyniki trafiają tam, gdzie zespół już patrzy.
- Bramki jakości na pull requestach
- Nocna regresja i przebiegi na żądanie
- Powiadomienia o wynikach dla zespołu
Ratowanie zestawu, któremu nikt nie wierzy
Zestaw, w którym połowa testów jest wyłączona, a czerwony wynik nikogo nie zatrzymuje, jest gorszy niż brak testów — daje złudzenie kontroli. Przejmujemy taki projekt: analizujemy przyczyny niestabilności, naprawiamy albo usuwamy testy bez wartości i doprowadzamy zestaw do stanu, w którym czerwony wynik znowu coś znaczy.
- Analiza i naprawa niestabilnych testów
- Usunięcie testów bez wartości diagnostycznej
- Skrócenie czasu wykonania zestawu
- Przekazanie zestawu zespołowi klienta
Typowe sytuacje
Pełna regresja ręczna zajmuje zespołowi kilka dni, więc przed pilnym wydaniem po prostu jej nie ma.
Testy automatyczne istnieją, ale świecą na czerwono od miesięcy i nikt już na nie nie patrzy.
Wydajecie kilka razy w tygodniu i potrzebujecie bramki, która zatrzyma zmianę psującą płatności.
Zespół potrafi pisać kod, ale nie ma nikogo, kto ustawi framework testowy tak, żeby dał się utrzymać.
Na czym możesz polegać
- Regresja przechodzi automatycznie przy każdej zmianie — bez blokowania kilku dni pracy zespołu.
- Wiesz, co zestaw pokrywa i czego świadomie nie pokrywa, i ile kosztuje jego utrzymanie.
- Czerwony wynik znowu coś znaczy, więc zespół reaguje na niego zamiast go pomijać.
- Testy w Twoim repozytorium, pisane jak produkcyjny kod — Twój zespół może je przejąć w każdej chwili.
Technologie
- Python
- PyTest
- REST API testing
- SQL
- GitHub Actions
- CI/CD
Pytania o tę usługę
Mniej, niż zwykle się zakłada. Kilkanaście testów na ścieżkach, które generują przychód — logowanie, koszyk, płatność, kluczowy formularz — zwraca się już po kilku wydaniach, bo zastępuje najbardziej powtarzalną część pracy ręcznej. Pełne pokrycie rzadko jest celem opłacalnym i nie proponujemy go domyślnie.
Nie i nie taki jest jej sens. Automat pilnuje tego, co się powtarza; człowiek znajduje to, czego nikt nie przewidział w scenariuszu. Automatyzacja zwalnia czas testera z klikania regresji na testy eksploracyjne nowych funkcji — i to jest właściwy podział pracy.
Zwykle tak, ale zaczynamy od odpowiedzi na pytanie, czy warto. Przeglądamy zestaw i dostajesz krótki raport: co działa, co jest niestabilne, co nie testuje niczego istotnego i ile pracy dzieli projekt od stanu używalnego. Jeśli szybciej i taniej jest napisać podstawowy zestaw od nowa, mówimy to wprost.
Ty decydujesz. Testy leżą w Twoim repozytorium, są udokumentowane i pisane w standardowym stosie, więc zespół może je przejąć — a przekazanie obejmuje omówienie struktury i zasad dopisywania nowych przypadków. Możesz też zostać przy stałym utrzymaniu zestawu po naszej stronie.
Powiązane usługi
Testowanie oprogramowania
Testy manualne i automatyczne, testy API, UI i regresji oraz strategia testów — proces jakości, który realnie zabezpiecza wydania.
DevOps i chmura
CI/CD, Docker, Terraform i AWS — żeby wdrożenia były jednym kliknięciem, a o awariach wiedzieć przed klientami, nie od nich.
Audyty techniczne
Audyty kodu, aplikacji, stron, procesów QA i infrastruktury. Zamiast opinii i zapewnień — pisemny raport z priorytetami i planem działania.
Sprawdźmy, co warto zautomatyzować w Twoim projekcie
Napisz, jak dziś wygląda regresja przed wydaniem i czego już próbowaliście. Odpowiemy konkretnie: co byśmy zautomatyzowali w pierwszej kolejności, czego nie i dlaczego.
- kontakt@jakubzajac.eu
- Telefon
- +48 573 021 012