Nowa wersja aplikacji może kompilować się bez błędów, a mimo to nie pozwalać się zalogować, zapisać zamówienia albo otworzyć kluczowego widoku. Smoke test to szybka kontrola najważniejszych funkcji, która odpowiada na jedno praktyczne pytanie: czy ta wersja nadaje się do dalszego, dokładniejszego testowania? Wyjaśniam, co powinien obejmować, jak przeprowadzić go ręcznie i automatycznie, czym różni się od sanity testu oraz jakie błędy najczęściej obniżają jego wartość.
Najważniejsze informacje o wstępnej kontroli aplikacji
- Cel: wykrycie awarii blokujących dalsze testy, a nie sprawdzenie każdej funkcji.
- Zakres: logowanie, uruchomienie aplikacji, główne ścieżki użytkownika i podstawowe integracje.
- Czas: zwykle od kilku do kilkunastu minut, zależnie od systemu i liczby scenariuszy.
- Decyzja: wynik powinien jasno wskazywać, czy zespół kontynuuje testy, czy odrzuca wersję.
- Automatyzacja: najlepiej uruchamiać ją po każdym wdrożeniu na środowisko testowe.
Najpierw sprawdź, czy wersja w ogóle nadaje się do testowania
Test dymny jest krótkim i szerokim sprawdzeniem podstawowej kondycji systemu. Nie zagłębia się w każdy wariant formularza ani nie mierzy pełnej zgodności z wymaganiami. Ma wykazać, że aplikacja uruchamia się, odpowiada na podstawowe działania i nie ma awarii tak poważnej, że dalsza praca testerów byłaby stratą czasu.
W praktyce zaczynam od funkcji, bez których produkt przestaje być użyteczny. Dla sklepu internetowego będą to między innymi otwarcie strony, wyszukanie produktu, dodanie go do koszyka, przejście do płatności i utworzenie zamówienia. Dla panelu biznesowego ważniejsze mogą być logowanie, odczyt danych z bazy, zapis zmian i wylogowanie.
To nie jest pełny test funkcjonalny. Jeżeli koszyk przyjmuje produkt, ale błędnie nalicza rabat dla jednego z kilkunastu wariantów, szybka kontrola może tego nie wykryć. I właśnie tak powinno być, ponieważ jej zadaniem jest znalezienie problemów blokujących podstawowe użycie, a nie zastąpienie regresji.
Co sprawdza się w pierwszej kolejności
- czy aplikacja uruchamia się bez błędu krytycznego,
- czy użytkownik może się zalogować lub przejść podstawową autoryzację,
- czy działa najważniejsza ścieżka biznesowa,
- czy kluczowe usługi i integracje odpowiadają,
- czy dane można odczytać i zapisać,
- czy aplikacja nie kończy działania przy zwykłym użyciu.
Granica między testem dymnym a testem akceptacyjnym bywa w firmach płynna. Ja traktuję tę pierwszą kontrolę jako bramkę wejściową do dalszych testów. Nie odpowiada ona na pytanie, czy produkt spełnia wszystkie potrzeby biznesowe, tylko czy w ogóle działa na tyle stabilnie, by warto było badać go dokładniej.
Co powinien obejmować dobry zestaw testów dymnych
Największy błąd polega na wybieraniu scenariuszy według tego, co najłatwiej przetestować. Lepszym kryterium jest ryzyko biznesowe. Funkcja może być technicznie prosta, ale jeśli jej awaria zatrzymuje sprzedaż, musi znaleźć się w zestawie kontrolnym.
| Obszar | Przykładowe sprawdzenie | Dlaczego ma znaczenie |
|---|---|---|
| Uruchomienie | Otwarcie aplikacji i głównego widoku | Wykrywa błędne wdrożenie, brak zasobów lub awarię startową |
| Dostęp | Logowanie poprawnym kontem testowym | Potwierdza działanie autoryzacji i podstawowej konfiguracji |
| Główna funkcja | Utworzenie zamówienia, zgłoszenia lub dokumentu | Sprawdza najważniejszy przepływ użytkownika |
| Dane | Odczyt i zapis rekordu | Może ujawnić problem z bazą, API albo uprawnieniami |
| Integracje | Połączenie z płatnością, pocztą lub usługą zewnętrzną | Pokazuje, czy system działa poza własną granicą |
Dobry zestaw jest krótki, ale nie przypadkowy. W małej aplikacji może liczyć 5-10 scenariuszy, a w dużym systemie kilkadziesiąt prostych kontroli podzielonych według modułów. Sama liczba nie jest najważniejsza. Jeśli testy trwają godzinę i sprawdzają szczegóły, których nie potrzebujemy na tym etapie, przestają pełnić swoją rolę.
W wielu projektach używa się określenia BVT, czyli Build Verification Test. Oznacza ono zestaw uruchamiany na nowej wersji w celu potwierdzenia, że kompilacja lub wdrożenie jest wystarczająco stabilne. Nazewnictwo może się różnić, dlatego ważniejsze od etykiety są jasno opisany zakres, warunek zaliczenia i reakcja na błąd.
Jak przeprowadzić kontrolę od wdrożenia do decyzji
Najpierw trzeba ustalić, na jakiej wersji pracujemy i jakie środowisko jest testowane. Bez numeru buildu, informacji o konfiguracji oraz przygotowanych danych wynik może być trudny do powtórzenia. Każdy test powinien dać się odtworzyć, nawet jeśli wykonuje go inna osoba.
- Potwierdź gotowość środowiska. Sprawdź, czy wdrożenie zakończyło się poprawnie, usługi działają, a konto testowe i dane wejściowe są dostępne.
- Uruchom podstawowe scenariusze. Zacznij od startu aplikacji, logowania i głównej ścieżki użytkownika, zamiast od pobocznych funkcji.
- Rejestruj konkretne wyniki. Zapisz wersję, datę, środowisko, wykonane kroki i komunikat błędu. Przy awarii przydadzą się także logi lub zrzut ekranu.
- Podejmij decyzję według ustalonej bramki. Jeden błąd krytyczny może oznaczać odrzucenie wersji, nawet gdy pozostałe scenariusze zakończyły się poprawnie.
- Przekaż wynik zespołowi. Informacja „nie działa” jest zbyt ogólna. Lepszy komunikat mówi, jaka wersja została sprawdzona, gdzie wystąpił problem i czy dalsze testy zostały zatrzymane.
Ręczna kontrola powinna zwykle zamknąć się w 5-15 minutach dla typowej aplikacji webowej, choć systemy z wieloma zależnościami mogą wymagać więcej czasu. Jeśli trwa znacznie dłużej, sprawdzam, czy zestaw nie rozrósł się do miniaturowej regresji. Jeśli trwa minutę, ale pomija logowanie, zapis danych i główną ścieżkę, prawdopodobnie jest zbyt płytki.
Wynik „niezaliczony” nie zawsze oznacza, że znaleziono błąd w kodzie. Przyczyną może być niedziałająca baza, wygasły sekret, brak danych testowych albo problem z usługą zewnętrzną. Dla zespołu efekt jest jednak podobny: nie powinien rozpoczynać pełnego testowania, dopóki nie wiadomo, dlaczego bramka została zamknięta.
Smoke, sanity i regresja to nie to samo
Te pojęcia często są używane zamiennie, ale opisują różne poziomy kontroli. W praktyce nazwy zależą od organizacji, dlatego zawsze sprawdzam, co zespół rozumie przez dany termin. Najważniejsza jest różnica w celu, szerokości i momencie wykonania.
| Rodzaj testu | Główny cel | Zakres | Kiedy go uruchomić |
|---|---|---|---|
| Test dymny | Ocena, czy wersja nadaje się do dalszych testów | Szeroki, ale płytki | Po nowym buildzie lub wdrożeniu |
| Sanity test | Sprawdzenie konkretnej zmiany lub poprawki | Węższy, bardziej skupiony | Po modyfikacji określonego obszaru |
| Test regresji | Potwierdzenie, że zmiany nie zepsuły istniejących funkcji | Szerszy i dokładniejszy | Przed wydaniem lub po większych zmianach |
| Test akceptacyjny | Ocena zgodności z potrzebą biznesową | Zależny od wymagań użytkownika | Przed formalnym odbiorem rozwiązania |
Przykład jest prosty. Po wdrożeniu nowej wersji najpierw sprawdzam, czy aplikacja działa w podstawowym zakresie. Jeśli poprawiono moduł faktur, wykonuję bardziej skupiony test sanity dotyczący faktury. Dopiero później uruchamiam regresję, która może obejmować płatności, raporty, uprawnienia i integracje.
Nie traktuję testu dymnego jako „małej regresji”. To inny instrument. Regresja ma szukać skutków zmian w szerokim obszarze, a szybka kontrola ma odpowiedzieć, czy w ogóle warto tę regresję uruchamiać.
Automatyzacja w CI/CD daje największy zwrot
Najlepszym miejscem dla tych testów jest potok CI/CD, czyli automatyczny proces budowania, sprawdzania i wdrażania aplikacji. Po utworzeniu nowej wersji system może uruchomić kilka krytycznych scenariuszy, a dopiero po ich zaliczeniu przekazać środowisko zespołowi QA. Krótki test działający przy każdym wdrożeniu szybko wykrywa problemy, które wcześniej czekałyby na ręczne sprawdzenie.
Nie wszystko trzeba od razu automatyzować przez interfejs. Dla API często wystarczy wysłanie żądania do najważniejszego endpointu, czyli punktu dostępu do konkretnej funkcji, i sprawdzenie kodu odpowiedzi, struktury danych oraz czasu reakcji. Dla aplikacji webowej można połączyć oba podejścia, używając kilku testów interfejsu dla krytycznej ścieżki i szybszych testów API dla pozostałych zależności.
Automatyzacja nie rozwiązuje jednak problemu złego zakresu. Test, który tylko sprawdza kod odpowiedzi 200, może przejść mimo pustej listy produktów albo błędnej treści odpowiedzi. Dlatego definiuję warunki zaliczenia na poziomie użytkownika i danych, a nie tylko na poziomie technicznego „serwer odpowiedział”.
Przeczytaj również: Testy niefunkcjonalne - Jak zapewnić jakość produktu?
Jak zaprojektować sensowną bramkę
- uruchamiaj ją po każdej wersji, która trafia na środowisko testowe,
- zatrzymuj dalszy etap po błędzie krytycznego scenariusza,
- utrzymuj testy niezależne od przypadkowych danych,
- czyść lub odtwarzaj dane po wykonaniu testu,
- zapisuj logi, zrzuty ekranu i identyfikator wersji,
- mierz czas wykonania i usuwaj testy, które nie dają użytecznego sygnału.
Warto także ustalić, kto reaguje na czerwony wynik. Automatyczny komunikat bez właściciela problemu niewiele zmienia. W dobrze działającym procesie awaria uruchamia jasną ścieżkę eskalacji, a zespół wie, czy naprawić kod, odtworzyć konfigurację, czy ponowić wdrożenie.
Błędy, przez które szybka kontrola traci sens
Pierwszy częsty błąd to dodawanie do zestawu wszystkiego, co wydaje się ważne. Po kilku miesiącach szybka bramka staje się wolnym i kruchym pakietem testów, którego nikt nie chce utrzymywać. Ja regularnie usuwam scenariusze, które nie sprawdzają podstawowej dostępności systemu albo dublują dokładniejsze testy.
- Brak jasnego celu. Jeśli nie wiadomo, jaką decyzję ma wspierać wynik, testy będą przypadkowe.
- Zbyt duża szczegółowość. Sprawdzanie każdego wariantu na tym etapie wydłuża proces i zaciera najważniejsze sygnały.
- Pomijanie integracji. Aplikacja może działać lokalnie, ale nie wysyłać wiadomości, nie pobierać danych lub nie zatwierdzać płatności.
- Niestabilne dane testowe. Wygasłe konto, zajęty numer dokumentu albo zmieniony produkt generują fałszywe alarmy.
- Brak kryterium odrzucenia. Jeżeli zespół mimo krytycznej awarii uruchamia kolejne testy, bramka jest tylko formalnością.
- Traktowanie automatyzacji jako gwarancji jakości. Zautomatyzowany zestaw nadal może być zbyt wąski i nie wykrywać realnych problemów.
Osobnego wyjaśnienia wymaga sytuacja, w której test przechodzi, ale użytkownicy nadal zgłaszają poważne błędy. To nie musi oznaczać, że kontrola jest bezużyteczna. Może po prostu obejmować wyłącznie ścieżkę „szczęśliwą”, czyli poprawne dane i typowy przebieg. Test dymny nie bada wyjątków, uprawnień, wydajności ani bezpieczeństwa, chyba że zespół świadomie dodał takie kontrole do bramki.
Dlatego po każdym incydencie sprawdzam, czy problem powinien trafić do zestawu podstawowego. Jeśli awaria uniemożliwiła większości użytkowników wykonanie głównej czynności, dodanie krótkiego scenariusza ochronnego ma sens. Jeśli dotyczyła rzadkiego wariantu, lepszym miejscem może być regresja lub test specjalistyczny.
Dobra bramka jakości nie musi być duża
Najlepszy zestaw testów dymnych nie próbuje udowodnić, że aplikacja jest bezbłędna. Ma szybko i uczciwie pokazać, czy nowa wersja jest wystarczająco stabilna, by poświęcić jej czas zespołu. W tym celu potrzebuje kilku krytycznych scenariuszy, powtarzalnych danych, jasnych kryteriów i właściciela reakcji na błąd.
Jeśli zaczynasz od zera, wybierz najpierw trzy ścieżki, bez których produkt traci sens. Uruchom je ręcznie po wdrożeniu, opisz oczekiwany wynik, a dopiero potem przenieś do CI/CD. Taka mała, dobrze zaprojektowana bramka zwykle daje więcej niż rozbudowany pakiet, który trwa długo, często się psuje i nie prowadzi do konkretnej decyzji.
