Краткий ответ

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

Исторический контекст

Оба подхода появились как практический способ получать быстрый сигнал о качестве сборки без немедленного запуска полного набора проверок. Командам требовалось рано отбрасывать явно непригодные версии и отдельно быстро оценивать небольшие изменения.

Термины не имеют единого обязательного стандарта: в разных командах границы между ними могут различаться. Поэтому на собеседовании важно опираться не только на название, но и явно описывать цель, охват и критерий принятия решения.

Постановка проблемы

Полный регрессионный набор часто занимает много времени. Если начать его на сборке, где невозможно войти в систему или выполнить ключевую операцию, ресурсы будут потрачены без полезного результата.

Обратная ситуация тоже рискованна: после небольшого исправления запускать весь регресс без предварительной узкой проверки может быть неэффективно. Если команда смешивает smoke и sanity, она может выбрать неправильный объём тестирования и ошибочно считать сборку проверенной.

Подробное решение

Smoke имеет следующие признаки:

охватывает основные пользовательские или системные потоки;
проверяет доступность критичных функций на базовом уровне;
выполняется быстро после установки новой сборки или существенного обновления;
его провал обычно означает, что дальнейшее тестирование сборки преждевременно.

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

Sanity имеет другой фокус:

охватывает изменённую функцию и непосредственно связанные области;
проверяет, что конкретное исправление или небольшая доработка работает по назначению;
помогает быстро решить, стоит ли переходить к более широкому регрессу;
обычно не претендует на оценку всей сборки.

Если исправили расчёт скидки, sanity может проверить разные типы скидок, итоговую сумму и ближайшие связанные сценарии. Это не означает, что вся корзина, каталог и личный кабинет уже прошли полноценную проверку.

Граница определяется не длительностью, а назначением и охватом. Smoke может быть дольше sanity, а sanity — включать сложные проверки; жёстких универсальных ограничений по времени нет. Оба подхода не заменяют полный регресс, исследовательское тестирование и проверки негативных сценариев.

Ситуация из практики

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

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

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

Что кандидаты часто упускают

1. Можно ли считать smoke и sanity взаимозаменяемыми, если набор проверок занимает одинаковое время?

Нет. Одинаковая длительность ничего не говорит о назначении проверки. Smoke оценивает общую пригодность сборки по критическим потокам, а sanity — влияние конкретного изменения на ограниченную область. Один и тот же тест может входить в оба набора, но решение о включении и интерпретация результата будут разными.

2. Что означает успешный smoke, если после него найден серьёзный дефект?

Успешный smoke означает только, что проверенные базовые потоки в данном окружении отработали приемлемо. Он не доказывает отсутствие дефектов в непроверенных функциях, редких комбинациях данных, производительности, безопасности или интеграциях. Поэтому результат smoke — это решение о возможности продолжать тестирование, а не итоговая оценка качества продукта.

3. Кто должен определять состав smoke и sanity-наборов?

Состав должен определяться совместно с учётом архитектуры продукта, критичности функций, истории дефектов и типа изменений. Тестировщик может предложить проверки, но критерии пригодности сборки и области риска должны быть согласованы с командой. Наборы нужно пересматривать: устаревший smoke может пропустить новый критический поток, а слишком широкий sanity перестанет быть быстрым и сфокусированным.