Smoke test: co to jest, kiedy go uruchamiać i czym różni się od sanity testu

Czas czytania: około 15 minut

Smoke test i sanity test to dwa pojęcia, które w wielu zespołach są używane zamiennie. To błąd, który prowadzi do chaosu w procesie QA, źle dobranych testów, niepotrzebnego blokowania wydań albo przeciwnie: przepuszczania wersji, która nie powinna przejść dalej.

Oba typy testów są szybkie, selektywne i mają pomóc zespołowi podjąć decyzję, czy warto przechodzić do kolejnych działań. Różnią się jednak celem, momentem wykonania, zakresem i głębokością. Smoke test odpowiada na pytanie: czy build lub wdrożona wersja w ogóle nadaje się do dalszych testów? Sanity test odpowiada na pytanie: czy konkretna zmiana, poprawka albo obszar działa sensownie po modyfikacji?

Jeżeli Wasza firma ma problem z ryzykownymi wdrożeniami, długą regresją, przypadkową automatyzacją albo brakiem jasnych kryteriów release, dobrym pierwszym krokiem jest audyt QA. Analizujemy w nim procesy, odpowiedzialności, komunikację, skuteczność testów i sposób podejmowania decyzji o wydaniach, a nie tylko listę przypadków testowych.

Czym jest smoke test?

Smoke test, czyli test dymny, to szybki zestaw testów sprawdzających, czy najważniejsze funkcje systemu działają na tyle poprawnie, aby można było rozpocząć dalsze testowanie. Słownik ISTQB definiuje smoke test jako zestaw testów obejmujących główną funkcjonalność komponentu lub systemu, wykonywany po to, aby określić, czy działa on prawidłowo przed rozpoczęciem planowanego testowania. Nazwa pochodzi z elektroniki: pierwszy test nowego urządzenia polegał na podłączeniu go do prądu i sprawdzeniu, czy nie idzie dym.

W praktyce smoke test jest pierwszym filtrem jakości. Nie ma udowodnić, że aplikacja jest gotowa do produkcji. Ma odpowiedzieć na pytanie, czy aplikacja nie jest fundamentalnie zepsuta. Smoke test może sprawdzać na przykład:

1. Czy aplikacja się uruchamia.
2. Czy użytkownik może się zalogować.
3. Czy główny ekran się ładuje i podstawowa nawigacja działa.
4. Czy połączenie z bazą danych działa.
5. Czy podstawowe API odpowiada.
6. Czy koszyk lub zamówienie przechodzi podstawową ścieżkę.
7. Czy panel administracyjny jest dostępny.
8. Czy wdrożona wersja nie zwraca błędów serwera na głównych ścieżkach.

Smoke test powinien być krótki, stabilny i szybki. Jeżeli trwa tyle co pełna regresja, przestaje spełniać swoją funkcję.

Czym jest sanity test?

Sanity test to szybka, ale bardziej ukierunkowana weryfikacja konkretnego obszaru po zmianie, poprawce lub modyfikacji. Sanity test nie sprawdza całej aplikacji. Sprawdza, czy dany fragment systemu zachowuje się logicznie i czy warto wykonywać dalsze testy w tym obszarze. Uwaga terminologiczna: słownik ISTQB traktuje sanity test jako synonim smoke testu, ale w praktyce zespołów te dwa testy odpowiadają na różne pytania i tak je rozróżniamy w tym tekście.

Przykład: developer naprawił błąd w naliczaniu rabatu. Sanity test nie musi sprawdzać całego sklepu internetowego. Powinien sprawdzić, czy poprawiony mechanizm rabatu działa w podstawowych scenariuszach i czy nie zepsuł najbliższych zależności, takich jak koszyk, cena końcowa i podsumowanie zamówienia. Sanity test może więc sprawdzać:

1. Czy poprawka błędu działa.
2. Czy zmieniona funkcja zachowuje się zgodnie z oczekiwaniem.
3. Czy najbliższe zależności nie zostały uszkodzone.
4. Czy warto przechodzić do szerszej regresji.
5. Czy użytkownik może wykonać podstawową akcję w zmienionym obszarze.
6. Czy zmiana nie wprowadziła oczywistego błędu w sąsiednim procesie.

Smoke test patrzy szeroko i płytko. Sanity test patrzy wężej, ale trochę głębiej.

Smoke test a sanity test: najważniejsze różnice

Najważniejsza różnica jest prosta. Smoke test sprawdza stabilność całego buildu lub wdrożenia na podstawowym poziomie. Sanity test sprawdza sensowność konkretnej zmiany lub poprawki. Smoke test uruchamiacie wtedy, gdy chcecie wiedzieć, czy warto zaczynać dalsze testy. Sanity test wtedy, gdy chcecie szybko potwierdzić, czy określony fragment aplikacji po zmianie działa wystarczająco dobrze, aby testować go dalej albo dopuścić do regresji.

Kiedy uruchamiać smoke test, a kiedy sanity test

Smoke test warto wykonywać zawsze wtedy, gdy pojawia się nowy build, nowe wdrożenie albo nowa wersja środowiska, a zespół musi szybko ocenić, czy warto przechodzić dalej. Sanity test ma sens po konkretnej zmianie lub poprawce, gdy zespół chce szybko sprawdzić, czy dany obszar działa logicznie i nie wymaga natychmiastowego cofnięcia do developmentu.

Jeżeli Wasza firma chce włączyć takie testy do procesu wydań, warto połączyć automatyzację testów z budową procesów CI/CD. Dzięki temu smoke testy nie są ręczną checklistą wykonywaną od czasu do czasu, ale stałym elementem kontroli jakości.

Smoke test, sanity test i regresja: kolejność w procesie

Smoke test, sanity test i regresja to trzy różne elementy procesu testowego. Smoke test jest szybkim sprawdzeniem, czy build jest testowalny. Sanity test jest szybkim sprawdzeniem, czy konkretna zmiana działa sensownie. Regresja sprawdza, czy zmiany nie zepsuły istniejących funkcji. Najczęstsza kolejność wygląda tak:

1. Nowy build trafia na środowisko.
2. Zespół uruchamia smoke test.
3. Jeżeli smoke test przechodzi, testerzy przechodzą do testów zmian.
4. Po poprawce konkretnego błędu wykonywany jest sanity test.
5. Następnie uruchamiana jest wybrana regresja.
6. Przed release wykonywana jest regresja krytycznych ścieżek.
7. Po wdrożeniu można wykonać smoke test produkcyjny.

Problem zaczyna się wtedy, gdy zespoły próbują zastąpić regresję smoke testem albo sanity testem. Oba mają ograniczony zakres i nie dają pełnej informacji o wpływie zmian na resztę systemu. Jeżeli regresja w Waszej firmie trwa zbyt długo albo jest wykonywana przypadkowo, warto uporządkować testy regresyjne oraz automatyzację testów.

Smoke test i sanity test w Agile i CI/CD

W Agile oba typy testów mają bardzo praktyczne zastosowanie. Sprinty są krótkie, zmiany częste, a zespół potrzebuje szybkiej informacji zwrotnej. Smoke test pomaga szybko ocenić, czy nowy build jest stabilny i czy testerzy mogą rozpocząć pracę. Sanity test pomaga potwierdzić, czy konkretna user story, bug fix albo zmiana w module ma sens po stronie funkcjonalnej.

W dobrze działającym zespole smoke test i sanity test nie są formalnością. Są mechanizmem ochrony czasu zespołu. Jeżeli build nie przechodzi smoke testu, zespół nie powinien tracić kilku godzin na szczegółowe testy funkcji, która działa na niestabilnym środowisku. Jeżeli poprawka nie przechodzi sanity testu, nie ma sensu uruchamiać pełnej regresji obszaru, który nadal nie działa w podstawowym scenariuszu. Jeżeli w Waszym zespole testy są wykonywane głównie pod koniec sprintu, a QA staje się wąskim gardłem, przeczytajcie o shift left testing, czyli przesuwaniu testów na początek procesu.

W pipeline CI/CD smoke test działa jako szybka kontrola po buildzie lub po wdrożeniu na środowisko i może sprawdzić:

1. Czy aplikacja się uruchomiła.
2. Czy główny endpoint odpowiada.
3. Czy logowanie działa.
4. Czy baza danych jest osiągalna.
5. Czy krytyczne API zwraca poprawny status.
6. Czy podstawowy proces użytkownika przechodzi.
7. Czy monitoring nie pokazuje błędów krytycznych po wdrożeniu.

Sanity testy również można automatyzować, ale częściej są wykonywane selektywnie po konkretnej zmianie. Jeżeli firma chce wdrożyć quality gates w pipeline, trzeba jasno ustalić, które smoke testy blokują przejście dalej, które sanity testy są wymagane po określonych zmianach i kto odpowiada za analizę wyników. W tym pomaga TestOps i QualityOps.

Ile kosztuje smoke test, który trwa za długo

Smoke test ma chronić czas zespołu, więc jego koszt mierzy się czasem. Dobry smoke test dla dużej aplikacji ma kilkanaście lub kilkadziesiąt testów i kończy się w minutach. Zły ma kilkaset przypadków, trwa długo i jest tak niestabilny, że zespół przestaje mu ufać. Wtedy zamiast filtrować, blokuje.

Liczby w pasku pochodzą z naszego projektu dla Argos, sklepu internetowego. Zakres obejmował automatyzację testów i uporządkowanie procesów QA. Regresja przed wydaniem skróciła się z pięciu dni do dziesięciu godzin, liczba błędów krytycznych na produkcji spadła o 46 procent, a liczba awarii w okresach szczytowych o 72 procent. Pierwszym krokiem w takich projektach jest zwykle właśnie porządny, automatyczny smoke test krytycznych ścieżek, bo to on decyduje, czy regresja w ogóle ma sens na tej wersji.

Cztery przykłady z praktyki

Smoke test dla aplikacji webowej

Smoke test dla aplikacji webowej powinien obejmować tylko najważniejsze ścieżki. Jego celem nie jest sprawdzenie wszystkich wariantów, ale szybka ocena, czy aplikacja działa na podstawowym poziomie:

1. Strona główna ładuje się bez błędu.
2. Użytkownik może się zalogować i wylogować.
3. Menu główne jest widoczne, lista danych w kluczowym module dostępna.
4. Użytkownik może utworzyć podstawowy obiekt i zapisać formularz z poprawnymi danymi.
5. API statusu aplikacji zwraca poprawną odpowiedź.
6. Panel administracyjny jest dostępny dla konta z właściwą rolą.
7. Aplikacja nie zwraca błędu serwera na głównych widokach.

Sanity test po poprawce błędu

Załóżmy, że użytkownicy zgłosili błąd: po zmianie adresu dostawy system nie przelicza kosztu wysyłki. Po poprawce sanity test sprawdza konkretny obszar:

1. Użytkownik może edytować adres dostawy.
2. Po zmianie miasta koszt wysyłki aktualizuje się poprawnie.
3. Po zmianie kraju dostępne są właściwe metody dostawy.
4. Podsumowanie zamówienia pokazuje poprawną cenę, zapis zamówienia działa.
5. API koszyka zwraca poprawne dane.
6. Komunikaty błędów pojawiają się dla niepoprawnego adresu.
7. Poprawka nie zepsuła płatności w podstawowym scenariuszu.

Smoke test dla API

Smoke test API sprawdza krytyczne endpointy i podstawową dostępność usług: endpoint health zwraca poprawny status, logowanie zwraca token dla poprawnych danych, profil zwraca dane zalogowanego użytkownika, lista produktów zwraca dane, utworzenie zamówienia działa dla podstawowego scenariusza, płatność testowa przyjmuje request, a żaden krytyczny endpoint nie zwraca błędu serwera. Do takich testów dobrze sprawdza się Postman oraz automatyzacja testów API. Podstawy opisujemy w tekstach Postman: testy integracyjne i testy API oraz Metody HTTP dla testera API.

Sanity test dla API

Załóżmy, że zespół zmienił endpoint odpowiedzialny za naliczanie rabatu. Sanity test API obejmuje: request z poprawnym kodem rabatowym zwraca oczekiwaną cenę, request z niepoprawnym kodem zwraca właściwy komunikat błędu, kod nie działa po dacie ważności i tylko dla właściwego typu produktu, API nie pozwala użyć rabatu wielokrotnie, jeżeli reguła tego zabrania, koszyk po rabacie ma poprawną kwotę końcową, a endpoint zamówienia przyjmuje koszyk z naliczonym rabatem. To dobry sanity test, bo sprawdza konkretną zmianę i najważniejsze zależności.

Jak zaprojektować dobry smoke test

Dobry smoke test powinien być minimalny, szybki, stabilny i powiązany z realnym ryzykiem biznesowym. Nie powinien być listą przypadkowych testów, które akurat łatwo zautomatyzować.

Zacznijcie od krytycznych ścieżek

Najpierw określcie, które procesy są absolutnie niezbędne, aby aplikacja mogła być dalej testowana albo używana: logowanie, dostęp do panelu, pobranie danych, utworzenie zamówienia, płatność testowa, wysłanie formularza, kluczowe API, połączenie z bazą danych, wylogowanie. Bez której funkcji aplikacja nie ma sensu dla użytkownika? Które obszary najczęściej psują się po zmianach? Które błędy powodują największe straty biznesowe?

Ograniczcie zakres

Smoke test nie powinien sprawdzać wszystkich wariantów. Ma wykrywać problemy krytyczne, a nie zastępować regresję. Zakres przeglądajcie regularnie, bo produkt się zmienia i krytyczne ścieżki też.

Ustalcie kryteria przejścia

Zespół powinien wiedzieć, co oznacza wynik. Jeżeli smoke test nie przechodzi, build wraca do developmentu. Jeżeli błąd dotyczy środowiska, analizuje go zespół infrastruktury. Jeżeli błąd dotyczy danych testowych, test nie blokuje release, ale wymaga korekty danych. Jeżeli błąd dotyczy krytycznej ścieżki użytkownika, release jest zablokowany. Bez jasnych kryteriów smoke test staje się tylko informacją, a nie narzędziem decyzyjnym.

Automatyzujcie tam, gdzie ma to sens

Smoke testy bardzo często warto automatyzować, ponieważ są wykonywane często i powinny dawać szybki feedback. Nie wszystkie muszą być testami UI. W wielu przypadkach lepsze będą testy API, bo są szybsze i stabilniejsze. Jeżeli zespół nie wie, które testy automatyzować jako pierwsze, dobrym krokiem jest doradztwo w automatyzacji testów.

Jak zaprojektować dobry sanity test

Dobry sanity test powinien być powiązany z konkretną zmianą. Nie powinien mieć stałego zakresu identycznego dla każdego release. Jego siłą jest dopasowanie do zmiany, a nie sztywna lista przypadków.

1. Zrozumcie zmianę. Co zostało zmienione, dlaczego, jakie moduły są zależne, jakie dane są potrzebne, jakie ryzyko niesie zmiana i jakie błędy historycznie pojawiały się w tym obszarze.
2. Sprawdźcie ścieżkę główną. Najpierw upewnijcie się, że poprawka działa w najbardziej typowym scenariuszu.
3. Dodajcie najważniejsze warianty negatywne. Sanity test nie musi być pełną regresją, ale powinien sprawdzić przypadki, które mogłyby szybko wykazać, że zmiana jest niepoprawna.
4. Sprawdźcie najbliższe zależności. Jeżeli zmiana dotyczy koszyka, sprawdźcie też podsumowanie zamówienia. Jeżeli dotyczy logowania, sprawdźcie sesję i wylogowanie. Jeżeli dotyczy API, sprawdźcie konsumenta tej odpowiedzi.
5. Zdecydujcie, co dalej. Po sanity teście zespół powinien wiedzieć, czy poprawka wraca do developera, czy można przejść do szerszej regresji, czy przekazać zmianę do testów akceptacyjnych.

Manualnie czy automatycznie

Smoke test może być manualny albo automatyczny. Wybór zależy od produktu, częstotliwości wydań, stabilności środowiska, kosztu automatyzacji i poziomu ryzyka. Sanity testy częściej bywają manualne lub półautomatyczne, ponieważ ich zakres zależy od konkretnej zmiany.

W praktyce najlepsze podejście łączy oba modele. Automatyzacja sprawdza powtarzalne ścieżki, a tester wykonuje szybkie testy eksploracyjne tam, gdzie potrzebna jest ocena człowieka. Dobre QA nie polega na automatyzowaniu wszystkiego. Polega na świadomym wyborze, które testy powinny być manualne, które automatyczne, a które nie są potrzebne. Kompetencje w tym obszarze budują szkolenia Automatyzacja testów Selenium oraz CI/CD dla testerów oprogramowania: Jenkins.

Najczęstsze błędy w smoke testach i sanity testach

Najgorsza sytuacja to smoke test, który nie przechodzi, ale zespół i tak testuje dalej, bo trzeba dowieźć. Wtedy test nie pełni roli bramki jakości i cała reszta procesu opiera się na złudzeniu.

Jak wdrożyć smoke testy i sanity testy w firmie

1. Zdefiniujcie krytyczne procesy. Nie zaczynajcie od narzędzi. Zacznijcie od biznesu i ryzyka.
2. Oddzielcie smoke test od sanity testu. Zespół powinien jasno rozumieć, że smoke test sprawdza stabilność buildu, a sanity test konkretną zmianę.
3. Ustalcie moment wykonania. Smoke test po nowym buildzie, po wdrożeniu na środowisko albo jako element pipeline. Sanity test po poprawce lub zmianie konkretnego obszaru.
4. Ustalcie kryteria decyzji. Wynik testu prowadzi do decyzji: kontynuujemy, blokujemy, cofamy, naprawiamy albo rozszerzamy testy.
5. Wybierzcie poziom automatyzacji. Smoke testy częściej warto automatyzować, sanity testy selektywnie.
6. Uporządkujcie dokumentację. Cel i zakres smoke testu, krytyczne ścieżki, czas wykonania, osoba lub proces odpowiedzialny, kryteria przejścia i kryteria blokujące release. Pomaga w tym tworzenie dokumentacji testowej.
7. Połączcie testy z pipeline. Jeżeli firma pracuje w CI/CD, smoke testy powinny być częścią procesu wdrożeniowego, a nie osobną czynnością po nim.
8. Regularnie przeglądajcie zakres. Smoke testy i sanity testy starzeją się. Produkt się zmienia, więc zakres testów musi być aktualizowany.

Jeżeli chcecie wdrożyć taki proces systemowo, dobrym początkiem jest audyt QA, a następnie strategia jakości oprogramowania. Materiały dla liderów jakości publikujemy też na portalu Strefa QA, a raz w roku branża testowania spotyka się na Testing Ground Conference.

Najczęstsze pytania o smoke test i sanity test

Co to jest smoke test?

Smoke test to szybki zestaw testów sprawdzających, czy podstawowe funkcje systemu działają i czy build nadaje się do dalszego testowania. Obejmuje krytyczne ścieżki, ale nie wchodzi w szczegółową weryfikację całej aplikacji.

Co to jest sanity test?

Sanity test to szybka, ukierunkowana weryfikacja konkretnej zmiany, poprawki albo wybranego obszaru aplikacji. Sprawdza, czy dana funkcja działa sensownie po modyfikacji i czy warto przechodzić do dalszych testów.

Czym różni się smoke test od sanity testu?

Smoke test jest szerszy i płytszy. Sprawdza, czy build działa na podstawowym poziomie. Sanity test jest węższy i bardziej skoncentrowany. Sprawdza konkretną zmianę lub poprawkę.

Kiedy wykonywać smoke test?

Smoke test wykonuje się po nowym buildzie, po wdrożeniu na środowisko testowe, po deployu na staging, po większej zmianie lub przed rozpoczęciem pełniejszej regresji.

Kiedy wykonywać sanity test?

Sanity test wykonuje się po konkretnej poprawce, zmianie funkcji, aktualizacji API, zmianie konfiguracji albo modyfikacji logiki biznesowej.

Czy smoke test zastępuje regresję?

Nie. Smoke test jest tylko szybkim filtrem, który mówi, czy aplikacja nadaje się do dalszego testowania. Regresja sprawdza, czy zmiany nie zepsuły istniejących funkcji.

Czy sanity test zastępuje regresję?

Nie. Sanity test sprawdza konkretny obszar po zmianie. Regresja ma szerszy zakres i sprawdza wpływ zmian na istniejące funkcje.

Czy smoke testy warto automatyzować?

Tak, szczególnie gdy są wykonywane często, po każdym buildzie albo w pipeline CI/CD. Automatyzacja smoke testów daje szybki feedback i pomaga blokować niestabilne wersje przed dalszym testowaniem.

Czy sanity testy warto automatyzować?

Czasami tak. Sanity testy warto automatyzować wtedy, gdy dotyczą często zmienianych obszarów, mają stabilne dane i są wykonywane regularnie. W wielu przypadkach sanity test pozostaje testem manualnym lub półautomatycznym.

Kto powinien wykonywać smoke testy i sanity testy?

Smoke testy i sanity testy mogą wykonywać testerzy manualni, QA Engineerowie, testerzy automatyzujący, developerzy albo pipeline CI/CD. Ważniejsze od osoby jest to, aby zakres, moment wykonania i kryteria decyzji były jasne dla całego zespołu.

Powiązane na blogu Quality Island

• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku
• Testy end to end: jak sprawdzić, czy cały system działa od początku do końca
• Typy testów oprogramowania: jak je rozumieć i kiedy stosować
• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Jak napisać plan testów: kompletny przewodnik

Pełna lista źródeł

• ISTQB Glossary, hasła smoke test i sanity test
• IBM, What is smoke testing?
• Microsoft Learn, testy UI w potoku ciągłej integracji
• Wikipedia, Smoke testing (software), w tym pochodzenie nazwy z testów sprzętu elektronicznego
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta