Odpowiedź.

Historia pytania:

Testowanie smoke („testowanie dymne”) pojawiło się jako szybki sposób na sprawdzenie funkcjonalności systemu po zbudowaniu. Jego celem jest upewnienie się, że krytyczne funkcje działają, a aplikacja w zasadzie nadaje się do dalszych, bardziej szczegółowych testów. W testowaniu manualnym testy smoke zazwyczaj wykonuje się zaraz po wdrożeniu nowej wersji produktu.

Problem:

Główną trudnością jest ograniczony czas i potrzeba wyboru rzeczywiście ważnych kontroli. Testujący często sprawdzają zbyt wiele (marnując zasoby), lub pomijają krytyczne kwestie, przez co do wydania mogą trafić "dziury".

Rozwiązanie:

Prawidłowa organizacja testowania smoke polega na wyborze ściśle minimalnego zestawu scenariuszy, obejmujących najważniejsze strumienie użytkowników. Te kontrole powinny być jasne, szybkie i powtarzalne. Na przykład:

- Udane logowanie użytkownika do systemu
- Możliwość wykonania podstawowej funkcji (na przykład, dokonanie zakupu)
- Dokonanie płatności i otrzymanie potwierdzenia

Kluczowe cechy:

Testy smoke obejmują tylko życiowo ważne funkcje
Szybkie wykonanie, co jest krytyczne przy częstych wydaniach
Wszystkie scenariusze są wykonywane ręcznie według wcześniej zatwierdzonej checklisty

Pytania z podstępem.

Czy testowanie smoke można uznać za pełnoprawną alternatywę dla testowania regresyjnego?

Nie, testowanie smoke koncentruje się tylko na "działa - nie działa" dla kluczowych funkcji. Aby znaleźć poważne, ale niejawne błędy, zawsze potrzebne jest pełne testowanie regresyjne.

Co robić, jeśli chociaż jeden test smoke nie został ukończony? Czy testowanie powinno być kontynuowane?

Nie, dalsze testowanie nie ma sensu — zespół raportuje problem, wydanie jest zablokowane, dopóki błąd nie zostanie naprawiony.

Czy testy smoke powinny obejmować kontrole scenariuszy edge-case?

Nie, testy smoke nie są przeznaczone do sprawdzania przypadków skrajnych. Są tylko do potwierdzenia samej możliwości działania podstawowych funkcji produktu.

Typowe błędy i antywzorce

Wykonywanie nadmiarowych testów, które nie są krytyczne dla funkcjonalności
Brak dokumentacji dotyczącej testów smoke (tester „trzyma wszystko w głowie”)
Ignorowanie oczywistych problemów na rzecz „raportności”

Przykład z życia

Negatywny przypadek

Test smoke został przeprowadzony na obszernym checklist, obejmującym mało znaczące funkcje. Zajęło to dużo czasu, dlatego wydanie zostało opóźnione o pół dnia.

Zalety:

Wykryto kilka nieoczywistych błędów

Wady:

Opóźnienie wydania
Wydano zasoby i czas na mało znaczące kontrole

Pozytywny przypadek

Test smoke koncentrował się tylko na najważniejszych scenariuszach. Szybko wykryto blokujący błąd i poinformowano zespół — wydanie zostało wstrzymane do poprawki.