Дымовое тестирование — это быстрая проверка новой версии программы, чтобы понять одну простую вещь: можно ли с ней вообще работать дальше. Не нужно искать все ошибки и проверять каждую мелочь. Достаточно убедиться, что приложение запускается, основные функции живы и ничего критического не сломалось.
Название пришло из электроники. Когда собирали новое устройство, его сначала включали «на дым»: если пошёл дым — дальше тестировать бессмысленно, сначала надо чинить. В программах логика такая же. Если свежая сборка даже не открывается или не пускает пользователя внутрь, нет смысла запускать длинные проверки. Сначала убеждаемся, что база работает, и только потом идём глубже.
Зачем это нужно
Представьте, что полное регрессионное тестирование занимает несколько часов. Команда запускает его на новой сборке и через полчаса выясняет: приложение не авторизует, главная страница падает, а API отвечает ошибкой. Время потеряно. Дымовой прогон решает эту проблему заранее. Он занимает обычно от пяти до тридцати минут и быстро показывает, стоит ли тратить на эту версию больше сил.
Для команды это ещё и понятный сигнал. Если дымовые проверки прошли, можно спокойно продолжать тестирование, показывать сборку заказчику или двигаться дальше по релизу. Если не прошли — работу лучше остановить и разбираться с блокирующей проблемой. Без такого фильтра команда часто тратит время на детальный разбор версии, которая изначально была непригодна для проверки.
Когда его проводят
Дымовое тестирование обычно делают после каждой новой сборки. Его запускают перед длинным регрессом, после выкладки на тестовый стенд и после серьёзных исправлений. Если команда готовится к приёмке со стороны бизнеса, smoke тоже помогает: сначала проверяют, что продукт хотя бы технически жив, и только потом передают его пользователям на оценку.
Это не разовая процедура перед релизом, а регулярная привычка. Чем чаще выкладываются новые версии, тем важнее быстро отсеивать явно сломанные сборки.
Чем оно отличается от других проверок
Часто путают дымовое, санитарное и регрессионное тестирование. Это разные задачи. Дымовое смотрит на всё приложение очень поверхностно и отвечает на вопрос: «сборка вообще жива?» Санитарное уже уже. Его делают, когда изменили что-то конкретное, например исправили оплату, и нужно быстро проверить именно эту область. Регрессионное идёт глубже и дольше. Оно ищет побочные эффекты изменений и покрывает гораздо больше сценариев.
Smoke не заменяет регресс. Это скорее первый порог. Сначала убеждаемся, что версия пригодна для работы, потом запускаем более тщательные проверки. Приёмочное тестирование тоже стоит отдельно: там бизнес смотрит, удобен ли продукт и выполняет ли он свою задачу. Дымовое же проверяет только техническую основу.
Что именно проверяют
В дымовой набор попадают самые важные сценарии, без которых продукт теряет смысл. Для сайта это может быть открытие главной страницы, вход в аккаунт, переход в основные разделы и один ключевой пользовательский путь от начала до конца. Например, пользователь зашёл, нашёл товар и дошёл до оформления заказа. Если даже это не работает, остальное можно не трогать.
Хороший дымовой набор короткий, быстрый и надёжный. Он не должен падать из-за мелких колебаний интерфейса или случайных задержек сети. В него обычно не включают редкие крайние случаи, проверку каждого поля формы или долгие нагрузочные испытания. Если набор разросся до сотен проверок и идёт часами, это уже не smoke, а регресс под другим именем.
Как его строят на практике
Сначала команда определяет критический путь пользователя. Это минимальный набор действий, который должен работать всегда. Потом из этого пути выбирают несколько коротких проверок и договариваются, что считается успехом. Обычно успех означает, что все базовые сценарии прошли и нет критических ошибок. Провал означает, что дальнейшее тестирование или выкладку лучше остановить.
На раннем этапе такие проверки можно делать вручную. Но в зрелых командах их почти всегда автоматизируют и встраивают в CI/CD, чтобы после каждой сборки smoke запускался сам. Это быстрее, честнее и снимает зависимость от того, кто именно сегодня на смене. При этом набор нужно поддерживать. Если изменилась авторизация, навигация или главный сценарий, smoke тоже надо обновить, иначе он перестанет отражать реальность.
Как это выглядит в процессе разработки
В типичном pipeline сначала собирают приложение, прогоняют unit-тесты, выкладывают версию на тестовое окружение и сразу после этого запускают smoke. Если он прошёл, можно идти дальше — к регрессу, более глубоким проверкам или подготовке к релизу. Если упал, pipeline останавливают и команда получает сигнал, что есть серьёзная проблема.
Здесь важны скорость и ясность. Дымовой прогон не должен тянуться слишком долго. Если он постоянно длится сорок минут и больше, набор, скорее всего, перегружен. Также важно сохранять следы падения: логи, скриншоты, видео, ответы API. Без этого разработчику будет сложно быстро понять, что именно сломалось.
Ручные и автоматические проверки
Ручной smoke удобен, когда продукт ещё молодой или команда только начинает выстраивать процесс. Его можно быстро собрать без сложной инфраструктуры, и человек сразу замечает странности, которые автоматизация может пропустить. Но при частых сборках ручной подход становится медленным и зависит от конкретного тестировщика.
Автоматический smoke даёт стабильность и повторяемость. Один и тот же набор запускается после каждой версии, результат виден всей команде, а история прогонов сохраняется. Минус в том, что автотесты нужно писать и поддерживать. Но для регулярных сборок это обычно окупается очень быстро. На практике часто оставляют автоматизированный базовый набор и короткий ручной чек-лист для нестандартных ситуаций.
Типичные ошибки
Самая частая проблема — когда smoke постепенно превращается в маленький регресс. В набор добавляют всё новые и новые проверки, прогон становится долгим, а команда теряет главную идею: быстро понять, жива ли сборка.
Вторая ошибка — нечёткие правила. Один тест упал, но никто не знает, можно ли идти дальше. Из-за этого smoke перестаёт быть фильтром и становится формальностью. Ещё хуже, когда в набор попадают нестабильные тесты, которые то проходят, то падают сами по себе. Через некоторое время команда перестаёт им доверять.
Бывает и обратная ситуация: smoke проверяет только внешний вид страницы, а серверная часть уже не работает. Для современных приложений полезно смотреть и на интерфейс, и на API, иначе можно получить ложное ощущение, что всё в порядке.
Что в итоге
Дымовое тестирование — это не формальность и не «галочка перед релизом». Это простой и очень практичный способ не тратить время на версии, которые ещё не готовы к нормальной проверке. Оно отвечает на базовый вопрос: можно ли продолжать работу с этой сборкой.
Если регрессионное тестирование спрашивает, не сломали ли мы что-то в процессе изменений, то дымовое спрашивает более фундаментальное: жива ли сама основа продукта. Хороший smoke короткий, понятный, стабильный и встроен в обычный рабочий процесс команды. Именно поэтому его используют почти везде, где версии собираются часто и ошибки на старте дорого обходятся.