Ad 1. Czym są smoke testy?

Termin "smoke test" funkcjonuje obecnie głównie w kontekście procesów wytwarzania oprogramowania, a zwłaszcza kontroli jakości. Jest mimo to terminem używanym również w innych dziedzinach. C.Kaner i J.Bach podają, że pojęcie bierze swój początek z żargonu elektryków i - dosłownie - oznaczało przetestowanie sprzętu pod kątem tak oczywistego problemu, że wydobywający się z urządzenia dym byłby przewidywanym kryterium niezaliczenia testu. 

W kontekście testowania oprogramowania i złożonych systemów informatycznych należy rozumieć smoke test (przekładany czasem na "test dymny") jako:

• test pobieżny (będzie to często test przeszukujący "wszerz", a nie "w głąb"; często będzie to test najbardziej typowej ścieżki czynności, którą może przebyć potencjalny użytkownik),
• test zajmujący niewiele czasu (ma szybko udzielić informacji koniecznych do podjęcia decyzji, co zrobimy dalej w ramach testowania), 
• test poszukujący bardzo wyraźnych problemów (test zdany pomyślnie powinien wykluczyć zachodzenie ewidentnej awarii na swojej ścieżce),
• test dopuszczający do kolejnego etapu prac (zwłaszcza w kontekście zaangażowania w tym kolejnym etapie znaczących zasobów). 

Dodatkowo - wśród poziomów testów definiowanych przez normę IEEE 829 (ISO/IEC/IEEE 29119) i obowiązujących do certyfikatów ISTQB smoke test najczęściej znajdziemy wymieniany jako kryterium rozpoczęcia testów systemowych. Ma on w takiej sytuacji potwierdzić zakończenie etapu integracji modułów składających się na system. 

Ad 2. Jak się je sporządza?

Nie ma sformułowanych kategorycznych zasad tworzenia smoke testów. Mogą być testami zarówno manualnymi, jak i zautomatyzowanymi. Najistotniejsze jest to, by czynności, które kolejno będziemy wykonywali w ramach smoke testów nie zaprzeczały podstawowym cechom smoke testów. Na przykład podczas manualnego testowania interfejsu użytkownika i przechodzenia przez sprawdzane funkcjonalności, nie powinniśmy zagłębiać się przesadnie w żadną z nich. Jeśli mamy do ustawienia kilka pól wyboru w oknie interfejsu, a następnie mamy przejść do następnego kroku w interfejsie, to nie będziemy sprawdzali wielu kombinacji nastaw, a ograniczymy się do najbardziej prawdopodobnej (zakładając dostępną wiedzę o typowych zachowaniach użytkownika końcowego). 

Ad 3. Kiedy są sporządzane?

Mogą być zaprojektowane zarówno we wczesnych etapach wytwarzania oprogramowania, kiedy ustalane są najistotniejsze ścieżki przechodzenia przez aplikację - możemy na przykład wybrać najbardziej priorytetowe albo ryzykowne przypadki użycia (use case'y) i zaprojektować smoke test, który przejdzie przez te z najistotniejszych dla klienta, które pokrywają najwięcej obszarów aplikacji za jednym zamachem. 

Nie wyklucza to możliwości tworzenia dodatkowych smoke testów później w procesie wytwarzania, gdy na przykład wydarzenia podczas projektu wskazują na prawdopodobieństwo zachodzenia "krytycznej" awarii. Bardzo typowe będzie dla zespołu testowego wykonywanie smoke testu, który konkretnie ma upewnić zespół, że, przykładowo, po ostatnim wdrożeniu najnowszej wersji systemu, ta wyjątkowo groźna awaria w znanym nam miejscu nie występuje.  

Ad 4. Co mają na celu sprawdzić?

Smoke test ma przede wszystkim na celu upewnić nas, że dotychczasowy etap budowania systemu jest już zamknięty i że można przechodzić do kolejnego etapu (na przykład testów systemowych, które wymagają innego środowiska i innego podejścia niż poprzedzające je testy integracyjne) bez ryzyka, że po pierwszych czynnościach nowego etapu będzie trzeba natychmiast wstrzymywać prace i wracać do poprzedniej fazy budowy. Można zatem powiedzieć, że ma on, dzięki swej zwięzłej i mało pracochłonnej formie, oszczędzić nam czas, który moglibyśmy stracić na drobiazgowe testowanie systemu, który na skutek niedopatrzeń w poprzedniej fazie powstawania w ogóle nie powinien zostać skierowany do kolejnego etapu.