Smoke test vs sanity test. Różnice i zastosowanie w praktyce QA

Smoke test i sanity test to dwa pojęcia, które w wielu zespołach są używane zamiennie. To błąd, który może 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?

Źródłowy artykuł Quality Island dobrze wskazuje, że testy dymne służą szybkiej weryfikacji podstawowych funkcji systemu po zmianach, a sanity testy koncentrują się bardziej na określonych funkcjonalnościach po poprawkach lub modyfikacjach. W tej wersji porządkujemy temat mocniej pod praktykę QA, automatyzację, CI/CD, regresję, decyzje release i realne problemy zespołów IT.

Jeżeli Twoja firma ma problem z ryzykownymi wdrożeniami, długą regresją, przypadkową automatyzacją albo brakiem jasnych kryteriów release, dobrym pierwszym krokiem jest audyt QA. Quality Island analizuje 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. 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.

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.
4. Czy podstawowa nawigacja działa.
5. Czy połączenie z bazą danych działa.
6. Czy podstawowe API odpowiada.
7. Czy krytyczny formularz można otworzyć.
8. Czy koszyk lub zamówienie przechodzi podstawową ścieżkę.
9. Czy panel administracyjny jest dostępny.
10. 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.

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 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 konkretna funkcja jest gotowa do dalszych testów.
6. Czy użytkownik może wykonać podstawową akcję w zmienionym obszarze.
7. Czy zmiana nie wprowadziła oczywistego błędu w sąsiednim procesie.

Sanity test jest więc bardziej skoncentrowany niż smoke test. Smoke test patrzy szeroko i płytko. Sanity test patrzy wężej, ale trochę głębiej.

Smoke test vs sanity test. Najważniejsza różnica

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 wykonujesz wtedy, gdy chcesz wiedzieć, czy warto zaczynać dalsze testy. Sanity test wykonujesz wtedy, gdy chcesz szybko potwierdzić, czy określony fragment aplikacji po zmianie działa wystarczająco dobrze, aby testować go dalej albo dopuścić do regresji.

Smoke test. Szeroko i płytko

Smoke test obejmuje krytyczne ścieżki systemu, ale nie wchodzi w szczegóły. Jego celem jest szybka odpowiedź: czy build jest testowalny?

Przykład smoke testu dla aplikacji e commerce:

1. Strona główna ładuje się poprawnie.
2. Użytkownik może się zalogować.
3. Lista produktów jest widoczna.
4. Produkt można dodać do koszyka.
5. Koszyk się otwiera.
6. Proces zamówienia przechodzi do płatności.
7. Panel administracyjny jest dostępny.
8. API produktów zwraca odpowiedź.

To nie jest pełna weryfikacja sklepu. To szybka kontrola, czy podstawowy szkielet aplikacji działa.

Sanity test. Wąsko i głębiej

Sanity test dotyczy konkretnej zmiany. Jest bardziej selektywny, ale powinien sprawdzić obszar dokładniej niż smoke test.

Przykład sanity testu po poprawce logowania:

1. Użytkownik może zalogować się poprawnym loginem i hasłem.
2. Użytkownik z błędnym hasłem otrzymuje właściwy komunikat.
3. Konto zablokowane nie może się zalogować.
4. Token sesji jest tworzony poprawnie.
5. Użytkownik po zalogowaniu trafia do właściwego panelu.
6. Wylogowanie działa.
7. Poprawka nie zepsuła resetu hasła.

To nadal nie jest pełna regresja. To szybka kontrola konkretnego obszaru.

Kiedy wykonywać smoke 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.

Najczęstsze momenty wykonania smoke testu:

1. Po utworzeniu nowego buildu.
2. Po wdrożeniu na środowisko testowe.
3. Po wdrożeniu na staging.
4. Po wdrożeniu na produkcję jako szybka kontrola podstawowej dostępności.
5. Po większym merge.
6. Po zmianie konfiguracji środowiska.
7. Po aktualizacji zależności.
8. Po migracji infrastruktury.
9. Po wdrożeniu hotfixa.
10. Przed rozpoczęciem pełnej regresji.

CircleCI opisuje smoke testy jako podstawowe testy sprawdzające krytyczne funkcje aplikacji po wdrożeniu. Wskazuje też, że pomagają one dawać szybki feedback i mogą być uruchamiane po deployu, przed promocją buildu do kolejnego środowiska lub jako element CI/CD.

Jeżeli Twoja 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.

Kiedy wykonywać sanity test?

Sanity test warto wykonywać po konkretnej zmianie lub poprawce, gdy zespół chce szybko sprawdzić, czy dany obszar działa logicznie i nie wymaga natychmiastowego cofnięcia do developmentu.

Najczęstsze momenty wykonania sanity testu:

1. Po poprawce błędu.
2. Po zmianie jednej funkcji.
3. Po zmianie walidacji formularza.
4. Po zmianie uprawnień.
5. Po zmianie logiki biznesowej.
6. Po aktualizacji endpointu API.
7. Po zmianie konfiguracji modułu.
8. Po zmianie w integracji.
9. Przed wykonaniem szerszej regresji danego obszaru.
10. Przed przekazaniem funkcji do testów akceptacyjnych.

Sanity test jest szczególnie przydatny wtedy, gdy zespół pracuje szybko, a każda poprawka wymaga decyzji: czy testujemy dalej, czy od razu wraca do developera?

Smoke test a sanity test w Agile

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 w Agile pomaga szybko ocenić, czy nowy build jest stabilny i czy testerzy mogą rozpocząć pracę.

Sanity test w Agile pomaga szybko potwierdzić, czy konkretna user story, bug fix albo zmiana w module ma sens po stronie funkcjonalnej.

W dobrze działającym zespole Agile 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, zespół nie powinien uruchamiać pełnej regresji obszaru, który nadal nie działa w podstawowym scenariuszu.

Jeżeli w Twoim zespole testy są wykonywane głównie pod koniec sprintu, a QA staje się wąskim gardłem, warto rozważyć strategię jakości oprogramowania albo przeczytać artykuł Shift Left Testing. Wady i zalety.

Smoke test a sanity test w DevOps i CI/CD

W DevOps smoke testy mają bardzo ważne miejsce, ponieważ wspierają szybkie i bezpieczniejsze dostarczanie zmian. Google Cloud opisuje CI jako częste integrowanie pracy, w którym każda integracja jest weryfikowana automatycznym buildem, co pomaga szybko wykrywać problemy integracyjne i ograniczać problemy później w procesie.

Smoke testy dobrze pasują do tego modelu, ponieważ mogą działać jako szybka kontrola po buildzie lub po wdrożeniu na środowisko.

W pipeline CI/CD smoke test może sprawdzić:

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

Sanity testy również mogą być automatyzowane, ale częściej są wykonywane selektywnie po konkretnej zmianie. W praktyce można je uruchamiać ręcznie, półautomatycznie albo jako część wybranego zestawu regresyjnego.

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 oraz budowa procesów CI/CD.

Smoke test a sanity test a regresja

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. To nie jest dobre podejście. Smoke test i sanity test mają ograniczony zakres. Nie dają pełnej informacji o wpływie zmian na resztę systemu.

Jeżeli regresja w Twojej firmie trwa zbyt długo albo jest wykonywana przypadkowo, warto uporządkować testy regresyjne oraz automatyzację testów.

Przykład smoke testu 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.

Przykładowy zakres smoke testu:

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

Taki smoke test powinien być możliwy do wykonania szybko. Jeżeli aplikacja jest krytyczna biznesowo, część tych testów warto zautomatyzować jako testy UI, API albo testy end to end.

Przykład sanity testu 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 powinien sprawdzić 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ę.
5. Zapis zamówienia działa.
6. API koszyka zwraca poprawne dane.
7. Komunikaty błędów pojawiają się dla niepoprawnego adresu.
8. Poprawka nie zepsuła płatności w podstawowym scenariuszu.

To jest sanity test, ponieważ dotyczy konkretnej poprawki i najbliższych zależności. Nie musi sprawdzać całej aplikacji.

Przykład smoke testu dla API

Smoke test API powinien sprawdzić krytyczne endpointy i podstawową dostępność usług.

Przykładowy zakres:

1. Endpoint health zwraca poprawny status.
2. Endpoint logowania zwraca token dla poprawnych danych.
3. Endpoint profilu zwraca dane zalogowanego użytkownika.
4. Endpoint listy produktów zwraca dane.
5. Endpoint tworzenia zamówienia działa dla podstawowego scenariusza.
6. Endpoint płatności testowej przyjmuje request.
7. Endpoint wylogowania działa.
8. Endpointy krytyczne nie zwracają błędów serwera.

Do takich testów dobrze sprawdza się Postman oraz automatyzacja testów API. Jeżeli chcesz lepiej zrozumieć podstawy, przeczytaj artykuł Postman. Testy integracyjne i testy API oraz Metody HTTP. Kompletny przewodnik dla testera API.

Przykład sanity testu dla API

Załóżmy, że zespół zmienił endpoint odpowiedzialny za naliczanie rabatu.

Sanity test API może obejmować:

1. Request z poprawnym kodem rabatowym zwraca oczekiwaną cenę.
2. Request z niepoprawnym kodem zwraca poprawny komunikat błędu.
3. Kod rabatowy nie działa po dacie ważności.
4. Kod rabatowy działa tylko dla właściwego typu produktu.
5. API nie pozwala użyć rabatu kilka razy, jeżeli reguła tego zabrania.
6. Koszyk po rabacie ma poprawną kwotę końcową.
7. Endpoint zamówienia przyjmuje koszyk z naliczonym rabatem.
8. Response nie zawiera nadmiarowych danych technicznych.

To dobry przykład sanity testu, ponieważ 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ć.

Zacznij od krytycznych ścieżek

Najpierw określ, które procesy są absolutnie niezbędne, aby aplikacja mogła być dalej testowana albo używana.

Przykłady:

1. Logowanie.
2. Dostęp do panelu.
3. Pobranie danych.
4. Utworzenie zamówienia.
5. Płatność testowa.
6. Wysłanie formularza.
7. Kluczowe API.
8. Połączenie z bazą danych.
9. Dostęp do konfiguracji.
10. Wylogowanie.

Ogranicz zakres

Smoke test nie powinien sprawdzać wszystkich wariantów. Ma wykrywać problemy krytyczne, a nie zastępować regresję.

Dobry smoke test dla dużej aplikacji może mieć kilkanaście lub kilkadziesiąt testów. Zły smoke test ma kilkaset przypadków, trwa długo i jest tak niestabilny, że zespół przestaje mu ufać.

Ustal kryteria przejścia

Zespół powinien wiedzieć, co oznacza wynik smoke testu.

Przykład:

1. Jeżeli smoke test nie przechodzi, build wraca do developmentu.
2. Jeżeli błąd dotyczy środowiska, zespół infrastruktury analizuje problem.
3. Jeżeli błąd dotyczy danych testowych, test nie blokuje release, ale wymaga korekty danych.
4. 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.

Automatyzuj 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 automatyzacja 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.

Zrozum zmianę

Tester powinien wiedzieć:

1. Co zostało zmienione.
2. Dlaczego zostało zmienione.
3. Jakie moduły są zależne.
4. Jakie dane są potrzebne.
5. Jakie ryzyko niesie zmiana.
6. Jakie błędy historycznie pojawiały się w tym obszarze.

Sprawdź ścieżkę główną

Najpierw upewnij się, że poprawka działa w najbardziej typowym scenariuszu.

Dodaj najważniejsze warianty negatywne

Sanity test nie musi być pełną regresją, ale powinien sprawdzić najważniejsze przypadki, które mogłyby szybko wykazać, że zmiana jest niepoprawna.

Sprawdź najbliższe zależności

Jeżeli zmiana dotyczy koszyka, sprawdź też podsumowanie zamówienia. Jeżeli dotyczy logowania, sprawdź też sesję i wylogowanie. Jeżeli dotyczy API, sprawdź konsumenta tej odpowiedzi.

Zdecyduj, co dalej

Po sanity teście zespół powinien wiedzieć:

1. Czy poprawka wraca do developera.
2. Czy można przejść do szerszej regresji.
3. Czy można przekazać zmianę do testów akceptacyjnych.
4. Czy potrzebne są dodatkowe testy ryzyka.

Smoke test i sanity test w decyzjach release

Smoke test i sanity test mają największą wartość wtedy, gdy wspierają decyzje jakościowe.

Nie chodzi o to, aby odhaczyć checklistę. Chodzi o to, aby odpowiedzieć na pytania:

1. Czy build nadaje się do testowania?
2. Czy środowisko działa?
3. Czy krytyczne ścieżki są dostępne?
4. Czy poprawka działa w podstawowym scenariuszu?
5. Czy regresja ma sens na tej wersji?
6. Czy release można kontynuować?
7. Czy ryzyko jest akceptowalne?
8. Czy potrzebujemy rollbacku?
9. Czy problem dotyczy aplikacji, środowiska, danych czy konfiguracji?
10. Czy biznes może zaufać tej wersji?

Jeżeli w Twojej firmie decyzje release są podejmowane bardziej na podstawie presji terminu niż danych o jakości, warto wdrożyć zarządzanie testami i QA albo strategię jakości oprogramowania.

Kto powinien wykonywać smoke testy i sanity testy?

To zależy od dojrzałości zespołu i poziomu automatyzacji.

Smoke testy mogą wykonywać:

1. Testerzy manualni.
2. QA Engineerowie.
3. Testerzy automatyzujący.
4. Developerzy po wdrożeniu na środowisko.
5. Pipeline CI/CD.
6. Zespół DevOps przy kontroli deployu.

Sanity testy mogą wykonywać:

1. Tester odpowiedzialny za dany obszar.
2. QA Engineer.
3. Developer przed przekazaniem poprawki do QA.
4. Product Owner w formie podstawowej weryfikacji biznesowej.
5. Tester automatyzujący jako część wybranego zestawu regresji.

W dojrzałym zespole smoke test nie jest wyłącznie obowiązkiem testera. Jeżeli build jest fundamentalnie zepsuty, cały zespół powinien być tym zainteresowany. QA dostarcza informację, ale jakość nie powinna być odpowiedzialnością jednej osoby.

Smoke test manualny czy automatyczny?

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.

Smoke test manualny ma sens, gdy:

1. Produkt często się zmienia wizualnie.
2. Zespół dopiero definiuje zakres testów.
3. Aplikacja jest mała.
4. Wdrożenia są rzadkie.
5. Nie ma jeszcze stabilnej automatyzacji.
6. Test wymaga oceny wizualnej lub eksperckiej.

Smoke test automatyczny ma sens, gdy:

1. Wdrożenia są częste.
2. Ten sam zakres jest powtarzany regularnie.
3. Testy muszą działać szybko.
4. Pipeline ma blokować wadliwe wersje.
5. Zespół chce ograniczyć ręczną regresję.
6. Kluczowe ścieżki są stabilne.
7. Testy API mogą szybko sprawdzić logikę systemu.

W praktyce najlepsze podejście często łączy oba modele. Automatyzacja sprawdza powtarzalne ścieżki, a tester manualny wykonuje szybkie testy eksploracyjne w miejscach, gdzie potrzebna jest ocena człowieka.

Jeżeli chcesz rozwinąć kompetencje w tym obszarze, sprawdź Automatyzację testów Selenium, Wprowadzenie do testowania API Postman oraz CI/CD dla testerów oprogramowania Jenkins.

Sanity test manualny czy automatyczny?

Sanity testy częściej bywają manualne lub półautomatyczne, ponieważ ich zakres zależy od konkretnej zmiany. Nie oznacza to jednak, że nie można ich automatyzować.

Sanity test warto automatyzować, gdy:

1. Dotyczy często zmienianego obszaru.
2. Scenariusz jest powtarzalny.
3. Dane testowe są stabilne.
4. Test ma jasne oczekiwane wyniki.
5. Poprawki w tym obszarze często powodują regresję.
6. Test można wykonać szybko przez API.
7. Wynik ma wspierać decyzję release.

Sanity test warto wykonać manualnie, gdy:

1. Zmiana jest jednorazowa.
2. Zakres nie jest jeszcze stabilny.
3. Potrzebna jest ocena UX.
4. Trzeba szybko zbadać zachowanie funkcji.
5. Tester musi użyć intuicji i doświadczenia.
6. Automatyzacja kosztowałaby więcej niż dałaby wartości.

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.

Smoke testy i sanity testy w dokumentacji QA

Smoke test i sanity test powinny być opisane w dokumentacji testowej, ale nie jako ciężka formalność. Chodzi o to, aby zespół wiedział, co testować, kiedy testować i co oznacza wynik.

Dobra dokumentacja powinna zawierać:

1. Cel smoke testu.
2. Zakres smoke testu.
3. Krytyczne ścieżki.
4. Czas wykonania.
5. Osobę lub proces odpowiedzialny.
6. Kryteria przejścia.
7. Kryteria blokujące release.
8. Zakres sanity testów dla typowych zmian.
9. Zależności między smoke testem, sanity testem i regresją.
10. Zasady aktualizacji testów.

Jeżeli dokumentacja testowa w Twojej firmie jest nieaktualna, zbyt obszerna albo nie wspiera decyzji, warto skorzystać z usługi tworzenie dokumentacji testowej albo szkolenia Tworzenie dokumentacji testowej.

Najczęstsze błędy w smoke testach

Błąd 1. Zbyt duży zakres

Smoke test ma być szybki. Jeżeli obejmuje zbyt wiele przypadków, traci sens i zaczyna przypominać regresję.

Błąd 2. Brak kryteriów blokujących

Zespół musi wiedzieć, które błędy blokują dalsze testy lub release. Bez tego smoke test nie wspiera decyzji.

Błąd 3. Testowanie przypadkowych ścieżek

Smoke test powinien obejmować krytyczne ścieżki biznesowe i techniczne, a nie funkcje wybrane dlatego, że łatwo je kliknąć.

Błąd 4. Brak automatyzacji przy częstych wdrożeniach

Jeżeli zespół wdraża często, a smoke test jest zawsze ręczny, QA szybko stanie się wąskim gardłem.

Błąd 5. Ignorowanie wyników

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.

Błąd 6. Niestabilne środowisko

Jeżeli smoke test często pada przez środowisko, a nie przez aplikację, zespół przestaje ufać testom. To sygnał, że trzeba poprawić środowiska, dane testowe albo proces deployu.

Najczęstsze błędy w sanity testach

Błąd 1. Mylenie sanity testu z regresją

Sanity test nie sprawdza całego systemu. Ma szybko potwierdzić sensowność konkretnej zmiany.

Błąd 2. Testowanie tylko ścieżki pozytywnej

Jeżeli poprawka dotyczy walidacji, ról albo danych, sanity test powinien uwzględniać także najważniejsze przypadki negatywne.

Błąd 3. Brak analizy wpływu zmiany

Tester powinien wiedzieć, jakie obszary mogą zostać dotknięte zmianą. Bez tego sanity test będzie zbyt wąski.

Błąd 4. Brak danych testowych

Sanity test po poprawce często wymaga konkretnych danych. Jeżeli ich nie ma, test jest opóźniony albo wykonywany na przypadkowych danych.

Błąd 5. Brak komunikacji z developerem

Sanity test powinien wynikać ze zrozumienia poprawki. Tester powinien wiedzieć, co zostało zmienione i gdzie może pojawić się ryzyko.

Błąd 6. Brak decyzji po teście

Po sanity teście zespół powinien wiedzieć, czy poprawka przechodzi dalej, czy wraca do developera. Bez decyzji test traci wartość.

Jak dobrać zakres smoke testu?

Dobry zakres smoke testu powinien wynikać z ryzyka i wartości biznesowej. Nie powinien być przypadkowy.

Przy wyborze testów zadaj pytania:

1. Bez której funkcji aplikacja nie ma sensu dla użytkownika?
2. Które procesy muszą działać po każdym wdrożeniu?
3. Które błędy blokują dalsze testowanie?
4. Które obszary najczęściej psują się po zmianach?
5. Które endpointy są krytyczne dla frontu?
6. Które integracje muszą być dostępne?
7. Które błędy powodują największe straty biznesowe?
8. Co powinno zostać sprawdzone przed pełną regresją?
9. Co powinno działać po wdrożeniu na produkcję?
10. Które testy można wykonać najszybciej i najbardziej stabilnie?

Zakres smoke testu powinien być przeglądany regularnie. Produkt się zmienia, więc krytyczne ścieżki też mogą się zmieniać.

Jak dobrać zakres sanity testu?

Zakres sanity testu powinien wynikać z konkretnej zmiany. Nie da się stworzyć jednej uniwersalnej listy sanity testów dla całego produktu.

Przy wyborze sanity testów zadaj pytania:

1. Co dokładnie zostało zmienione?
2. Jaki błąd miał zostać naprawiony?
3. Jakie wymaganie zostało zmodyfikowane?
4. Jakie moduły korzystają z tego samego mechanizmu?
5. Jakie dane są potrzebne do testu?
6. Jakie przypadki negatywne są najważniejsze?
7. Jaki scenariusz użytkownika może zostać dotknięty zmianą?
8. Czy zmiana wpływa na API?
9. Czy zmiana wpływa na role i uprawnienia?
10. Czy zmiana wpływa na raporty, płatności, dane albo integracje?

Sanity test powinien być elastyczny. Jego siłą jest dopasowanie do zmiany, a nie sztywna lista przypadków.

Smoke test i sanity test w e commerce

W e commerce smoke test powinien chronić najważniejsze ścieżki sprzedażowe.

Przykładowy smoke test:

1. Strona główna działa.
2. Lista produktów działa.
3. Produkt można dodać do koszyka.
4. Koszyk działa.
5. Checkout się otwiera.
6. Płatność testowa jest dostępna.
7. Użytkownik może się zalogować.
8. Panel administracyjny działa.

Sanity test w e commerce może dotyczyć konkretnej zmiany, na przykład kodów rabatowych, kosztów dostawy, integracji płatności albo promocji.

Jeżeli e commerce ma dużo zmian, integracji i ryzyko błędów produkcyjnych, warto połączyć smoke testy z testami funkcjonalnymi, testami wydajności i testami bezpieczeństwa.

Smoke test i sanity test w aplikacjach SaaS

W SaaS smoke test powinien sprawdzić podstawową dostępność usługi, logowanie, role, główne moduły i krytyczne API.

Przykładowy smoke test:

1. Aplikacja jest dostępna.
2. Logowanie działa.
3. Dashboard się ładuje.
4. Główny moduł pokazuje dane.
5. Użytkownik może utworzyć podstawowy obiekt.
6. Użytkownik może edytować dane.
7. API zwraca odpowiedzi.
8. Wylogowanie działa.

Sanity test może dotyczyć nowego raportu, zmiany uprawnień, poprawki w filtrowaniu danych albo nowej logiki naliczania limitów.

W SaaS szczególnie ważne są role i uprawnienia, dlatego sanity testy powinny często obejmować różne typy kont. To obszar, w którym warto łączyć testy funkcjonalne z testami bezpieczeństwa aplikacji.

Smoke test i sanity test w aplikacjach mobilnych

W aplikacjach mobilnych smoke test powinien sprawdzić, czy aplikacja się uruchamia, czy użytkownik może się zalogować, czy główne widoki działają i czy komunikacja z API jest poprawna.

Przykładowy smoke test:

1. Aplikacja uruchamia się bez błędu.
2. Ekran logowania jest widoczny.
3. Logowanie działa.
4. Główny ekran się ładuje.
5. Podstawowa akcja użytkownika działa.
6. Aplikacja komunikuje się z API.
7. Wylogowanie działa.

Sanity test może dotyczyć konkretnej poprawki, na przykład błędu w powiadomieniach, zmianie formularza, walidacji numeru telefonu albo obsłudze trybu offline.

Jeżeli zespół rozwija aplikacje mobilne, warto rozważyć automatyzację testów mobilnych oraz szkolenia z Appium, takie jak Testowanie automatyczne aplikacji mobilnych Appium Java lub Appium Python.

Smoke test i sanity test a testy API

W wielu projektach część smoke testów i sanity testów warto przenieść z UI na API. Testy API są często szybsze, stabilniejsze i lepiej pokazują, czy logika backendu działa.

Przykładowy smoke test API:

1. Health endpoint działa.
2. Logowanie zwraca token.
3. Profil użytkownika zwraca dane.
4. Lista produktów zwraca dane.
5. Utworzenie zamówienia działa.
6. Endpoint płatności testowej odpowiada.

Przykładowy sanity test API:

1. Poprawiony endpoint zwraca właściwy status.
2. Response ma oczekiwaną strukturę.
3. Walidacja błędnych danych działa.
4. Uprawnienia są sprawdzane.
5. Zmienione pole jest zgodne z dokumentacją.
6. Najbliższe zależności API działają.

Jeżeli zespół chce rozwinąć ten obszar, dobrym krokiem jest Wprowadzenie do testowania API Postman oraz automatyzacja testów API.

Smoke test i sanity test a testy bezpieczeństwa

Smoke test i sanity test zwykle nie są pełnymi testami bezpieczeństwa, ale mogą zawierać podstawowe kontrole, które szybko wykrywają krytyczne problemy.

Przykłady podstawowych kontroli bezpieczeństwa w smoke lub sanity:

1. Użytkownik bez tokena nie ma dostępu do danych.
2. Użytkownik zwykły nie ma dostępu do panelu administracyjnego.
3. Użytkownik nie może podejrzeć danych innego konta.
4. Endpoint nie zwraca nadmiarowych danych.
5. Komunikat błędu nie ujawnia szczegółów technicznych.
6. Sesja wygasa zgodnie z oczekiwaniem.
7. Wylogowanie unieważnia dostęp.

To nie zastępuje pełnych testów bezpieczeństwa, ale pomaga szybciej wychwytywać oczywiste ryzyka po zmianach w rolach, logowaniu, sesji albo API.

Jeżeli produkt przetwarza dane klientów, dokumenty, płatności lub dane wrażliwe, warto wykonać testy bezpieczeństwa aplikacji oraz rozwijać kompetencje przez Cybersecurity Testy bezpieczeństwa.

Smoke test i sanity test a dostępność

W podstawowych zestawach smoke i sanity można uwzględnić także szybkie kontrole dostępności. Nie zastąpią one pełnych testów WCAG, ale mogą wykryć oczywiste problemy po wdrożeniu.

Przykłady:

1. Strona główna ma widoczny fokus klawiatury.
2. Logowanie jest możliwe z klawiatury.
3. Główne przyciski mają czytelne etykiety.
4. Formularz pokazuje komunikaty błędów.
5. Kontrast krytycznych elementów nie jest oczywiście zepsuty.
6. Modal można zamknąć z klawiatury.

Jeżeli dostępność jest wymagana prawnie lub biznesowo, szybkie kontrole powinny być uzupełnione przez testy dostępności WCAG oraz szkolenie Testowanie dostępności cyfrowej.

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

Krok 1. Zdefiniuj krytyczne procesy

Najpierw ustal, które procesy muszą działać zawsze. Nie zaczynaj od narzędzi. Zacznij od biznesu i ryzyka.

Krok 2. Oddziel smoke test od sanity testu

Zespół powinien jasno rozumieć, że smoke test sprawdza stabilność buildu, a sanity test sprawdza konkretną zmianę.

Krok 3. Ustal moment wykonania

Smoke test powinien być wykonywany po nowym buildzie, po wdrożeniu na środowisko albo jako element pipeline.

Sanity test powinien być wykonywany po poprawce lub zmianie konkretnego obszaru.

Krok 4. Ustal kryteria decyzji

Wynik testu powinien prowadzić do decyzji: kontynuujemy, blokujemy, cofamy, naprawiamy albo rozszerzamy testy.

Krok 5. Wybierz poziom automatyzacji

Nie każdy test musi być automatyczny. Smoke testy częściej warto automatyzować. Sanity testy warto automatyzować selektywnie.

Krok 6. Uporządkuj dokumentację

Zakres testów, odpowiedzialności i kryteria powinny być opisane tak, aby zespół mógł z nich korzystać.

Krok 7. Połącz testy z pipeline

Jeżeli firma pracuje w CI/CD, smoke testy powinny być częścią procesu wdrożeniowego. Google Cloud wskazuje, że CI pozwala często integrować zmiany i weryfikować integracje automatycznym buildem, a CD pomaga dostarczać przyrostowe zmiany użytkownikom w sposób bezpieczniejszy i szybszy.

Krok 8. Regularnie przeglądaj zakres

Smoke testy i sanity testy starzeją się. Produkt się zmienia, więc zakres testów musi być aktualizowany.

Jeżeli chcesz wdrożyć taki proces systemowo, dobrym początkiem jest audyt QA, a następnie strategia jakości oprogramowania i TestOps i QualityOps.

Jak Quality Island może pomóc?

Quality Island pomaga firmom uporządkować testy smoke, testy sanity, regresję, automatyzację i proces release tak, aby testowanie nie było przypadkową checklistą, ale realnym mechanizmem kontroli ryzyka.

Jeżeli nie masz pewności, czy obecny proces testów rzeczywiście chroni produkt, zacznij od audytu QA. Audyt pozwala sprawdzić, czy problemy wynikają z braku strategii, zbyt późnego testowania, słabej automatyzacji, niejasnych kryteriów release, niestabilnych środowisk czy braku zarządzania ryzykiem.

Jeżeli potrzebujesz zaprojektować skuteczny model testowania, sprawdź strategię jakości oprogramowania oraz szkolenie Strategia testowania od A do Z. Jeżeli celem jest automatyzacja smoke testów i regresji, dobrym kierunkiem będzie automatyzacja testów, automatyzacja testów API oraz budowa procesów CI/CD.

Jeżeli chcesz rozwijać kompetencje zespołu, warto zacząć od Tester manualny, ISTQB Certyfikowany Tester, Wprowadzenie do testowania API Postman, Tworzenie dokumentacji testowej oraz Zarządzanie testami oprogramowania.

Warto też korzystać z ekosystemu Quality Island. Praktyczne materiały znajdziesz w Strefie QA, możliwości rozwoju i współpracy w QA Board, a społeczność i wydarzenia branżowe na Testing Ground.

Co czytać dalej?

Jeżeli chcesz uporządkować podstawy testowania, przeczytaj Testowanie oprogramowania. Rodzaje, techniki i proces oraz Jak zostać testerem oprogramowania.

Jeżeli chcesz lepiej projektować zakres testów, sprawdź Jak napisać plan testów oraz Sylabus ISTQB Certyfikowany Tester. Nowa wersja 4.0 vs 3.1.

Jeżeli interesuje Cię automatyzacja i API, przeczytaj Postman. Testy integracyjne i testy API, Metody HTTP. Kompletny przewodnik dla testera API oraz Testy automatyczne. Automatyzacja testów.

Jeżeli chcesz lepiej rozumieć nowoczesne podejście do jakości, sprawdź Shift Left Testing. Wady i zalety oraz Shift Right Testing.

Podsumowanie

Smoke test i sanity test są krótkimi, praktycznymi testami wspierającymi szybkie decyzje jakościowe, ale nie są tym samym.

Smoke test sprawdza, czy build, wdrożenie albo aplikacja działa na podstawowym poziomie i nadaje się do dalszego testowania. Jest szeroki, płytki i często wykonywany po nowym buildzie lub deployu.

Sanity test sprawdza, czy konkretna zmiana, poprawka albo wybrany obszar działa sensownie po modyfikacji. Jest węższy, bardziej ukierunkowany i pomaga zdecydować, czy warto przechodzić do dalszej regresji.

Oba testy mają największą wartość wtedy, gdy są dobrze zaprojektowane, powiązane z ryzykiem, osadzone w procesie QA i wspierają decyzje release. Nie zastępują regresji, testów bezpieczeństwa, testów wydajności ani testów akceptacyjnych. Są pierwszym filtrem, który chroni zespół przed stratą czasu i biznes przed ryzykownym wdrożeniem.

Jeżeli chcesz uporządkować smoke testy, sanity testy, regresję i automatyzację w swojej organizacji, zacznij od audytu QA albo strategii jakości oprogramowania. Jeżeli chcesz wdrożyć je w pipeline, właściwym kierunkiem będzie automatyzacja testów i budowa procesów CI/CD.

FAQ

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 test?

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 nie zastępuje regresji. 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 jednak 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.