Najważniejsze rzeczy, które warto zapamiętać
- Test dymny sprawdza tylko najważniejsze ścieżki, a nie cały system.
- Uruchamia się go wcześnie, zwykle po buildzie, deployu albo dużej zmianie.
- Dobrze zrobiony zestaw ma 3-7 kluczowych scenariuszy i trwa kilka minut, nie kilkadziesiąt.
- To nie jest regresja ani pełne testy end-to-end, choć łatwo je ze sobą pomylić.
- Największą wartość daje wtedy, gdy jest stabilny, krótki i zautomatyzowany.
Czym są testy dymne i co naprawdę sprawdzają
Według ISTQB to zestaw testów obejmujący główną funkcjonalność komponentu lub systemu. Ja tłumaczę to prościej: test dymny odpowiada na jedno pytanie, czy baza produktu działa na tyle stabilnie, by nie blokować dalszych testów.
To nie jest miejsce na pełne pokrycie scenariuszy. Chodzi raczej o kilka szybkich sprawdzeń, które pokażą, czy aplikacja wstaje, czy da się zalogować, czy zapis działa i czy najważniejsze operacje nie wywracają systemu po pierwszym kliknięciu. W praktyce sprawdzam zwykle 3-7 krytycznych ścieżek, nie 30 wariantów tego samego ekranu.
- uruchomienie aplikacji lub środowiska,
- logowanie albo inny podstawowy punkt wejścia,
- najważniejsza transakcja biznesowa,
- zapis danych,
- odczyt kluczowych danych albo przejście między modułami.
Największa wartość tego etapu polega na oszczędzaniu czasu. Jeśli podstawowa funkcjonalność się sypie, nie ma sensu marnować godzin na dokładniejsze scenariusze. Skoro zakres jest tak wąski, pojawia się pytanie: kiedy ten filtr ma największy sens?
Kiedy warto je uruchamiać w pipeline
Atlassian pokazuje, że taki etap można wpiąć w pipeline tak, aby potwierdzał stan produktu po wdrożeniu. Ja traktuję go jako punkt kontrolny po każdym zdarzeniu, które może złamać podstawowy przepływ: po buildzie, po deployu na stagingu, po zmianie konfiguracji i po integracjach z zewnętrznymi usługami.
W praktyce dobrze działający zestaw powinien zamykać się w 5-10 minutach. Gdy regularnie przekracza 15-20 minut, zwykle przestaje być szybkim filtrem, a zaczyna blokować zespół bardziej, niż pomaga.
- po nowym buildzie, zanim ruszą głębsze testy,
- po wdrożeniu na staging lub preprodukcję,
- po zmianie konfiguracji, flag funkcji albo zależności,
- po dużej migracji danych lub refaktorze w krytycznym module,
- przed przekazaniem wersji do dalszej walidacji.
Najprostsza zasada brzmi: jeśli awaria uniemożliwia sensowne testowanie reszty systemu, test dymny powinien wykryć to od razu. Z takiego podejścia naturalnie wynika kolejne pytanie: jak zbudować sam zestaw, żeby nie rozrósł się do mini-regresji?
Jak zbudować zestaw, który nie rozrośnie się do mini-regresji
Ja zwykle zaczynam od mapy najważniejszych ścieżek biznesowych. Jeśli produkt sprzedaje subskrypcję, sprawdzam wejście, logowanie, zakup, płatność i dostęp do konta. Jeśli to panel administracyjny, ważniejsze będą autoryzacja, wyszukiwanie, zapis rekordu i podstawowe akcje na danych.
Wybierz tylko to, co naprawdę definiuje działanie produktu
Jeśli w zestawie pojawia się wszystko, co „fajnie byłoby sprawdzić”, to już pierwszy sygnał ostrzegawczy. Test dymny ma być krótki i bezdyskusyjny, więc powinien obejmować tylko te kroki, bez których dalsze testy nie mają sensu. W praktyce najczęściej mieszczę się w 3-7 scenariuszach.
Uprość dane i warunki startowe
Najgorszy test dymny to taki, który wymaga ręcznego przygotowania środowiska, tworzenia specjalnego konta i odtwarzania półproduktowych danych. Jeśli setup trwa dłużej niż sam test, cały pomysł traci wartość. Lepiej mieć jednoznaczne dane wejściowe, stabilny stan startowy i przewidywalny wynik.
Ustal jasne kryteria zaliczenia
Tu nie ma miejsca na interpretację. Albo aplikacja startuje, logowanie działa i kluczowa operacja przechodzi, albo zestaw kończy się błędem. Ja pilnuję, żeby każdy przypadek miał jednoznaczne kryterium typu pass/fail, bez „prawie dobrze” i bez ręcznego zgadywania, czy wynik jest wystarczająco poprawny.
Przeczytaj również: Testy jednostkowe - Jak pisać, by przyspieszyć pracę?
Automatyzuj to, co powtarzalne
Jeśli scenariusz jest powtarzalny, stabilny i często uruchamiany, powinien trafić do automatyzacji. Ręczne testy zostawiam tam, gdzie produkt jest jeszcze bardzo młody albo proces zmienia się zbyt szybko. W dłuższej perspektywie ręczne odtwarzanie tego samego zestawu kliknięć po każdym buildzie po prostu nie skaluje się dobrze.
Gdy zestaw jest już ustawiony, trzeba jeszcze odróżnić go od podobnych typów testów, bo tu najczęściej pojawia się chaos nazewnictwa.
Czym różnią się od sanity, regresji i testów end-to-end
W wielu zespołach terminy są używane zamiennie, a potem wszyscy dziwią się, że mówią o czymś innym. Ja wolę prostą tabelę, bo od razu widać różnice w zakresie i celu.
| Typ testu | Zakres | Kiedy uruchamiać | Główny cel | Ryzyko pomyłki |
|---|---|---|---|---|
| Test dymny | Bardzo wąski, tylko krytyczne ścieżki | Przed dalszym testowaniem, po buildzie lub wdrożeniu | Szybko odrzucić wadliwy build | Łatwo rozrosnąć go do mini-regresji |
| Sanity | Wąski, zwykle wokół konkretnej zmiany | Po poprawce albo małej zmianie | Potwierdzić, że poprawka działa | Często mylony z testem dymnym |
| Regresja | Szeroki, obejmuje wiele obszarów | Po większej zmianie lub przed releasem | Sprawdzić, czy nic się nie zepsuło | Za ciężka, by używać jej jako szybkiego filtra |
| Testy end-to-end | Pełny przepływ użytkownika przez system | Gdy trzeba zweryfikować całość procesu | Zobaczyć zachowanie systemu od końca do końca | Bywają wolne i bardziej kruche |
Jeśli twoja organizacja używa tych nazw trochę inaczej, nie walczyłbym o słownikową czystość. Ważniejsze jest to, żeby zespół miał spisany wspólny zakres i wiedział, co dokładnie uruchamia się pod jaką nazwą. Kiedy definicje są już rozdzielone, łatwiej zobaczyć, co najczęściej psuje cały pomysł w codziennej pracy.
Najczęstsze błędy, które zabijają ich wartość
- Zbyt szeroki zakres - jeśli zestaw zaczyna sprawdzać wszystko po trochu, przestaje być szybkim filtrem. Wtedy trzeba odchudzić go do kilku naprawdę krytycznych ścieżek.
- Niestabilne zależności - zewnętrzne API, kolejki, płatności testowe i inne usługi potrafią generować fałszywe alarmy. Jeżeli nie są celem testu, warto je izolować lub stubować.
- Złe dane startowe - brak przewidywalnych danych sprawia, że testy losowo przechodzą albo padają. To jeden z najprostszych sposobów na utratę zaufania do całego zestawu.
- Brak właściciela - jeśli nikt nie pilnuje utrzymania, testy szybko się starzeją. Każdy martwy scenariusz obniża wiarygodność wyniku.
- Brak progu stopu - trzeba jasno ustalić, kiedy pipeline ma się zatrzymać. Bez tego „szybka weryfikacja” zamienia się w rutynowe ignorowanie błędów.
- Mylenie z regresją - gdy test dymny zaczyna obejmować zbyt dużo przypadków, robi się z niego mini-regresja. To zły kompromis, bo tracisz szybkość i nie zyskujesz pełnego pokrycia.
Po tych pułapkach zostaje już tylko pytanie, jak utrzymać zestaw w pipeline tak, żeby pomagał, a nie przeszkadzał.
Jak je automatyzować bez dokładania szumu
Ja automatyzuję przede wszystkim rzeczy powtarzalne: start aplikacji, logowanie, utworzenie podstawowego rekordu, odczyt statusu i jedną operację końcową. Jeśli scenariusz wymaga ręcznego przygotowania środowiska albo zmienia się co sprint, najpierw upraszczam proces, dopiero potem zapisuję go jako test.
- uruchamiaj zestaw po buildzie i po deployu na środowisko testowe,
- zatrzymuj pipeline po pierwszym krytycznym błędzie,
- loguj dokładnie, która ścieżka padła i na jakim kroku,
- taguj takie testy osobno, żeby nie mieszać ich z regresją,
- izoluj zależności zewnętrzne, jeśli nie są celem testu.
Wersja manualna ma sens tylko przejściowo, na przykład przy prototypie albo bardzo małym produkcie. W dojrzałym projekcie szybka weryfikacja podstawowych funkcji powinna być zautomatyzowana, inaczej każdy release zamienia się w ręczne odtwarzanie tych samych kilku kliknięć. Zostaje jeszcze pytanie, gdzie taki filtr daje największy zwrot z inwestycji.
Gdzie test dymny daje największy zwrot z inwestycji
Najwięcej zysku widzę tam, gdzie wdrożenia są częste, a koszt awarii wysoki: w produktach SaaS, systemach z płatnościami, aplikacjach z kilkoma zależnościami zewnętrznymi i w zespołach, które wypuszczają zmianę kilka razy w tygodniu albo częściej. W takich warunkach test dymny nie jest dodatkiem, tylko pierwszą linią obrony przed blokadą całego pipeline'u.
- produkty z szybkim tempem releasów,
- systemy krytyczne biznesowo,
- aplikacje z płatnościami, logowaniem i autoryzacją,
- architektury oparte na wielu usługach i integracjach,
- zespoły, które chcą skrócić czas reakcji na wadliwy build.
Jeśli mam zostawić jedną praktyczną zasadę, to tę: test dymny ma być krótki, stabilny i bezdyskusyjny. Gdy przestaje spełniać te trzy warunki, trzeba go odchudzić albo przerzucić część scenariuszy do regresji. Wtedy naprawdę zaczyna działać jak filtr jakości, a nie jak kolejny obowiązek w kalendarzu zespołu.
