Dwie godziny do release'u. Nie testuj wszystkiego, tylko właściwe rzeczy

Dlaczego "przeklikam jak najwięcej" jest najgorszą strategią?

8/25/2026

Scenariusz pewnie znasz: sprint się pali, release zaplanowany za dwie godziny, a testów rozpisanych na dwa dni nikt nie odwołał. Nikt też nie przyszedł powiedzieć, że skoro czasu jest cztery razy mniej, to zakres też się zmniejsza. Zwykle po prostu pada pytanie, czy da się to jakoś sprawdzić do siedemnastej.

Przez długi czas w takich momentach działałem chaotycznie - otwierałem aplikację i próbowałem sprawdzić jak najwięcej, byle szybciej. Efekt był taki, że testowałem dużo, ale przypadkowo, a potem nie potrafiłem powiedzieć zespołowi, co właściwie zostało zweryfikowane. Największy problem nie polegał na tym, że coś przeoczyłem, tylko na tym, że nie wiedziałem, co przeoczyłem.

Z czasem wypracowałem sobie prostą kolejność działań, której trzymam się za każdym razem, gdy czasu jest mniej niż zadań. Nie jest to metodyka ani nic, co da się wpisać do procesu - to raczej cztery kroki, które w tej konkretnej kolejności dają najwięcej informacji o ryzyku na jednostkę czasu. Poniżej opisuję każdy z nich razem z tym, co robię, gdy pierwszy krok pokaże coś niepokojącego.

Dlaczego "przeklikam jak najwięcej" jest najgorszą strategią

Przy dwóch godzinach do wdrożenia intuicja podpowiada, żeby zwiększyć tempo i objąć jak największy obszar aplikacji. To działa dokładnie odwrotnie, bo szybkie przechodzenie przez wiele ekranów daje płytkie pokrycie tam, gdzie nic się nie zmieniło, i zerowe tam, gdzie ryzyko jest realne. Kończy się notatką w stylu "przetestowane, wygląda ok", która nie niesie żadnej informacji dla osoby podejmującej decyzję o wdrożeniu.

Testowanie w warunkach niedoboru czasu to zadanie z priorytetyzacji, a nie z prędkości. Nie da się przetestować wszystkiego nawet w dwa dni, więc dwie godziny tylko wyostrzają problem, który istnieje zawsze. Różnica polega na tym, że przy większym budżecie czasu chaotyczne podejście da się ukryć, a przy dwóch godzinach widać je natychmiast.

Wartość QA w takim momencie mierzy się jakością decyzji, a nie liczbą klikniętych ekranów. Dobra decyzja brzmi: sprawdziliśmy te trzy obszary, tutaj jest ryzyko, tego świadomie nie ruszaliśmy. Zła decyzja to zielony kciuk bez uzasadnienia, który przy awarii na produkcji zamienia się w pytanie "przecież testowałeś, jak to przeszło?".

1. Sprawdź, co faktycznie się zmieniło

Nie chodzi o to, co jest w zakresie sprintu, tylko o to, co realnie zostało dotknięte w kodzie. Zakres sprintu to plan sprzed dwóch tygodni, a mnie interesuje rzeczywistość: zmiany, które weszły przy okazji, refaktoryzacje zrobione "bo i tak byłem w tym pliku" oraz aktualizacje bibliotek. To właśnie te rzeczy najczęściej wywołują awarie, bo nikt nie zaplanował dla nich testów.

Najszybszym źródłem tej wiedzy nie jest system do zarządzania zadaniami, tylko rozmowa z developerami. Pytam wprost: co ruszaliście, co mogło się przy okazji zepsuć, czego się obawiacie? Trzecie pytanie jest najważniejsze, bo devowie zwykle doskonale wiedzą, gdzie zostawili niepewne miejsce, tylko rzadko zgłaszają to z własnej inicjatywy. Taka rozmowa zajmuje dziesięć minut i potrafi zaoszczędzić godzinę bezcelowego klikania.

Do tego dochodzi rzut oka na listę zmienionych plików w pull requestach wchodzących do tego wydania - nie musisz czytać kodu linia po linii, żeby zobaczyć, że zmiany dotknęły modułu autoryzacji albo warstwy komunikacji z API. Jeśli pracujesz w projekcie, gdzie masz dostęp do repozytorium, to jest najtańsza forma shift-left, czyli włączania QA wcześniej niż na etapie gotowej funkcji. Zwykle wystarczy, żeby przesunąć plan testów o kilka pozycji i sprawdzić coś, czego nie było w pierwotnym zakresie.

2. Smoke test na krytycznych ścieżkach

Zanim wejdę w szczegóły zmian, odpowiadam na najbardziej podstawowe pytanie: czy aplikacja w ogóle wstaje i czy da się przez nią przejść. Sprawdzam główne przepływy biznesowe, czyli zwykle logowanie, kluczowy feature produktu i płatność albo inny krok, na którym zarabia firma. To są rzeczy, które muszą być na zielono, bo jeśli one nie działają, wyniki wszystkich pozostałych testów przestają mieć znaczenie.

Smoke test - czyli szybka weryfikacja, że kluczowe funkcje systemu odpowiadają - powinien zajmować minuty, nie kwadranse. Jeśli masz te ścieżki zautomatyzowane w Playwrightcie czy innym frameworku, ten krok robi się praktycznie sam, a Ty w tym czasie wracasz do rozmowy z devami. Jeśli nie masz, to właśnie dostałeś najlepszy możliwy argument, żeby automatyzację zacząć od tych kilku scenariuszy zamiast od pełnej regresji.

W praktyce widzę, że zespoły automatyzują od najłatwiejszych scenariuszy, a nie od najważniejszych, i po roku mają dwieście testów, z których żaden nie pilnuje płatności. Odwrócenie tej kolejności zmienia rolę automatów w dniu wdrożenia - z ciekawostki w raporcie stają się pierwszym źródłem informacji o stanie systemu. Jeśli piszesz takie testy w Playwrightcie i chcesz mieć pod ręką gotowe komendy, locatory i asercje, przygotowałem darmowy Playwright Starter Pack - czterdzieści stron ściągawki, które skracają pisanie stabilnych scenariuszy e2e.

3. Obszary zależne od zmiany

Każda zmiana ma skutki uboczne, dlatego po sprawdzeniu samej funkcji patrzę na moduły obok. Zmiana w koszyku oznacza, że sprawdzam też checkout i podsumowanie zamówienia, bo dane przechodzą przez wszystkie trzy widoki. Zmiana w uprawnieniach oznacza, że sprawdzam widoki, które te uprawnienia konsumują, łącznie z tymi, do których dana rola nie powinna mieć dostępu.

To jest moment, w którym najbardziej procentuje wiedza domenowa, czyli rozumienie, jak system działa od strony biznesu, a nie tylko interfejsu. Im lepiej znasz produkt, tym szybciej wiesz, gdzie zmiana może promieniować i które integracje są wrażliwe. Tester, który dołączył do projektu miesiąc temu, tego nie odgadnie i będzie potrzebował podpowiedzi od zespołu - i to jest normalne, o ile o nią poprosi.

Pomaga tu prosta rzecz, którą warto zbudować poza gorączką wdrożenia: mapa zależności między głównymi modułami, choćby na jednej kartce. Wystarczy lista w stylu "zmiana w cenniku dotyka koszyka, faktur i raportów sprzedażowych", żeby przy kolejnym pośpiechu nie odtwarzać tej wiedzy od zera. U mnie taka notatka kilka razy skróciła etap planowania do dwóch minut.

4. Retest bugów zamkniętych w tym sprincie

Fix może działać poprawnie i jednocześnie psuć coś obok, bo naprawa błędu to też zmiana w kodzie. Widziałem to zbyt wiele razy, żeby ten krok pomijać, zwłaszcza przy poprawkach robionych na szybko w ostatnich dniach sprintu. Poprawki wdrażane pod presją czasu mają statystycznie większą szansę na skutki uboczne niż zaplanowana funkcja, bo powstają bez review na spokojnie i bez rozmowy o wymaganiach.

Przechodzę więc przez bugi zamknięte w tym sprincie i sprawdzam nie tylko sam scenariusz z buglogu, ale też jego najbliższe otoczenie. Jeśli błąd dotyczył walidacji jednego pola, patrzę na cały formularz i na to, co dzieje się z danymi po zapisie. Retest samego kroku z opisu błędu daje fałszywe poczucie domknięcia tematu, bo weryfikuje dokładnie ten jeden przypadek, który developer miał przed oczami przy naprawie.

Przy bardzo krótkim czasie ograniczam ten krok do bugów o wysokim priorytecie i tych, które dotyczyły krytycznych ścieżek. Reszta trafia na listę do sprawdzenia po wdrożeniu, razem z informacją, że nie została zweryfikowana przed wypuszczeniem. To jest kompromis, ale świadomy i opisany, a nie taki, o którym nikt nie wie.

Co świadomie odpuszczam i dlaczego mówię o tym głośno

Te cztery kroki nie dają pełnego pokrycia i nie mają go dawać. Zawsze zostaje obszar, którego nie sprawdzę: rzadkie konfiguracje, przeglądarki spoza głównego ruchu, scenariusze administracyjne czy raporty generowane raz w miesiącu. Różnica między testowaniem chaotycznym a świadomym polega właśnie na tym, że w drugim przypadku potrafię wymienić z nazwy to, czego nie zweryfikowałem.

Efektem takiej sesji nie powinien być kciuk w górę, tylko krótka notatka dla zespołu i osoby decyzyjnej. Wystarczy kilka zdań: co zostało sprawdzone, co wygląda ryzykownie, czego nie zdążyłem ruszyć i co proponuję zrobić po wdrożeniu. Dzięki temu decyzja o wypuszczeniu zmiany przestaje być decyzją testera, a staje się decyzją biznesu podjętą przy pełnej informacji - i tak być powinno, bo to biznes ponosi konsekwencje awarii.

Do notatki dokładam plan na okno po wdrożeniu, bo część ryzyka można przenieść na etap po releasie. Smoke test na produkcji zaraz po wdrożeniu, sprawdzenie logów i monitoringu przez pierwszą godzinę, gotowy scenariusz wycofania zmiany - to wszystko obniża koszt ewentualnego błędu bardziej niż dodatkowe czterdzieści minut klikania przed wypuszczeniem.

Jak sprawić, żeby te dwie godziny nie były paniką

Najlepsza praca do wykonania w tym temacie dzieje się poza dniem wdrożenia. Lista krytycznych ścieżek uzgodniona z Product Ownerem, zautomatyzowany smoke, przygotowane dane testowe i mapa zależności między modułami sprawiają, że pośpiech przestaje być improwizacją. Każdy z tych elementów da się zbudować w kilka godzin rozłożonych na kilka sprintów, a korzystasz z nich za każdym razem, gdy termin się skraca.

Warto też potraktować powtarzalność tego scenariusza jako sygnał procesowy, a nie jako element pracy testera. Jeśli "dwie godziny na testy" zdarza się co sprint, problem nie leży w testowaniu, tylko w planowaniu i w tym, że jakość jest ostatnią pozycją w kolejce. To jest temat na retrospektywę, poparty konkretami: ile razy w ostatnich trzech miesiącach zakres testów został ścięty i co z tego wynikło na produkcji.

Zbieranie tych danych ma jeszcze jedną zaletę - zamienia rozmowę o presji czasu z narzekania w argument. Trudno dyskutować z listą pokazującą, że trzy z pięciu awarii w ostatnim kwartale dotyczyły obszarów, które świadomie odpuszczono przed wdrożeniem. Bez takiej listy zostaje wrażenie, że QA po prostu chciałby mieć więcej czasu.

Rola QA to decyzja, nie przeklikanie

Kiedy czasu jest mniej niż zadań, praca testera przestaje polegać na wykonywaniu scenariuszy, a zaczyna na zarządzaniu ryzykiem. Kolejność, którą opisałem - realne zmiany, smoke na krytycznych ścieżkach, obszary zależne, retest fixów - jest tylko narzędziem do tego, żeby w ograniczonym czasie zebrać maksimum informacji o stanie systemu. Samo jej odhaczenie nic nie da, jeśli na końcu nie zapadnie świadoma decyzja o tym, co musi działać, co może poczekać, a co odpuszczamy z pełną świadomością konsekwencji.

Testowanie to coś więcej niż klikanie, a przy dwóch godzinach do wdrożenia widać to najwyraźniej. Ten sam czas można spędzić na chaotycznym przechodzeniu przez aplikację albo na czterech krokach, które kończą się notatką realnie wspierającą decyzję biznesową. Różnica nie polega na liczbie sprawdzonych ekranów, tylko na tym, czy ktokolwiek wie, co właściwie zostało sprawdzone.

Jeśli chcesz uporządkować takie podejście u siebie od podstaw - priorytetyzację ryzyka, świadome testy eksploracyjne i pracę z wymaganiami zamiast odklikiwania przypadków testowych - opisałem to szerzej w e-booku Testowanie to coś więcej niż klikanie.