Odpowiedź.

Testowanie smoke i testowanie regresyjne to ważne rodzaje testowania ręcznego, stosowane na różnych etapach rozwoju i wypuszczania aktualizacji.

Historia pytania:

Test smoke (od „smoke test” w elektronice — sprawdzenie, czy po włączeniu urządzenia nie idzie „dym”) to szybkie minimalne sprawdzenie, czy główne funkcje systemu działają. Testowanie regresyjne to pełne lub częściowe ponowne sprawdzenie funkcjonalności w celu upewnienia się, że nowy kod nie naruszył istniejących funkcji.

Problem:

Często te testy są mylone lub stosowane niepoprawnie, co prowadzi do marnowania czasu lub pomijania ważnych sprawdzeń. Pojawiają się również pytania, jak i według jakich kryteriów formować zestawy testów dla testów smoke i regresyjnych.

Rozwiązanie:

Testy smoke obejmują tylko krytyczną funkcjonalność, bez której system nie działa w ogóle.
Testy smoke są przeprowadzane po każdej wdrożenia na testowe środowisko.
Testy regresyjne to szerszy zestaw sprawdzeń, obejmujących zmiany, pokrewne obszary i główną funkcjonalność.
Regres jest przeprowadzany po poprawkach i naprawach błędów, często przed wydaniem.

Kluczowe cechy:

Smoke sprawdza „żywotność” produktu — pomaga szybko zrozumieć, czy warto kontynuować dalsze testowanie.
Regres wykrywa błędy związane z już zrealizowaną funkcjonalnością.
Oba rodzaje testowania powinny być wyraźnie rozdzielone i udokumentowane.

Pytania z podchwytliwością.

Czy testowanie smoke wchodzi w skład testów regresyjnych?

Nie, smoke to podzbiór szczególnych „żywotnych” testów, podczas gdy regres obejmuje zarówno nowe, jak i ważne stare sprawdzenia.

Czy można przeprowadzać tylko testy smoke przed wydaniem?

Nie — to za mało. Smoke tylko sygnalizuje, że wszystko jest „żywe”, ale nie gwarantuje braku krytycznych błędów w mniej „publicznej” funkcjonalności.

Czy dopuszczalne jest zmienianie składu testów smoke przy każdej wersji?

Nie, skład smoke jest stabilny i zmienia się tylko przy radykalnych zmianach produktu.

Typowe błędy i antywzorce

Włączać do testów smoke zbyt wiele nieistotnych sprawdzeń.
Mieszać testy smoke i regresyjne, łącząc je w jedno uruchomienie.
Zapominać o aktualizacji testów regresyjnych przy zmianie funkcjonalności.

Przykład z życia

Negatywny przypadek

Przed wydaniem zespół ogranicza się tylko do testów smoke, nie przeprowadza testowania regresyjnego. W rezultacie błędy są odkrywane w mało widocznych, ale ważnych funkcjach dopiero po wydaniu.

Zalety:

Szybkie przejście testów.

Wady:

Wysokie ryzyko przeoczenia poważnych błędów.
Wzrost liczby zapytań od użytkowników.

Pozytywny przypadek

Po każdym wdrożeniu na testowe środowisko najpierw przeprowadzają testy smoke, a potem — regresyjne według aktualizowanych scenariuszy. Dokumentują wyniki i szybko dopracowują testy przy zmianach w produkcie.