Ответ.

Smoke-тестирование и регрессионное тестирование — важные виды ручного тестирования, применяемые на разных этапах разработки и выпуска обновлений.

История вопроса:

Smoke-тест (от “smoke test” в электронике — проверка, не идет ли «дым» после включения прибора) — это быстрая минимальная проверка, что основные функции системы работоспособны. Регрессионное тестирование — это полная или частичная перепроверка функционала для убеждения, что новый код не нарушил существующие функции.

Проблема:

Часто эти тесты путают или применяют некорректно, теряя время либо пропуская важные проверки. Также возникают вопросы, как и по каким критериям формировать наборы тестов для smoke и regression.

Решение:

Smoke-тесты включают только критическую функциональность, без которой система не работает вообще
Smoke-тесты выполняются после каждого деплоя на тестовое окружение
Регрессионные тесты — это более широкий набор проверок, покрывающих изменения, смежные области и основной функционал
Регресс проводится после доработок и багфиксов, часто перед релизом

Ключевые особенности:

Smoke проверяет "жизнеспособность" продукта — помогает быстро понять, стоит ли проводить дальнейшее тестирование
Регресс выявляет баги, связанные с уже реализованным функционалом
Оба типа тестирования должны быть четко разделены и документированы

Вопросы с подвохом.

Входит ли smoke-тестирование в регрессионное?

Нет, smoke — подмножество особых «жизненно важных» тестов, а регресс включает в себя и новые, и важные старые проверки.

Можно ли запускать только smoke-тесты перед релизом?

Нет — этого недостаточно. Smoke только сигнализирует, что всё "живое", но не гарантирует отсутствие критических багов в менее «публичной» функциональности.

Допустимо ли менять состав smoke-тестов на каждом релизе?

Нет, состав smoke стабильный и меняется только при радикальных изменениях продукта.

Типовые ошибки и анти-паттерны

Включать в smoke-тесты слишком много незначительных проверок
Путать smoke и регрессионные тесты, объединяя их в один прогон
Забывать обновлять регрессивные тесты при изменении функционала

Пример из жизни

Негативный кейс

Перед релизом команда ограничивается только smoke-тестами, не проводит регрессионное тестирование. В результате обнаруживаются баги в малозаметных, но важных функциях уже после релиза.

Плюсы:

Быстрое прохождение тестов

Минусы:

Высокий риск пропустить серьезные баги
Возрастание числа обращений пользователей

Позитивный кейс

После каждого деплоя на тестовое окружение проводят сначала smoke-тесты, а потом — регрессионные по обновляемым сценариям. Документируют результаты и оперативно дорабатывают тесты при изменениях в продукте.