Ответ.

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

Smoke-тесты (smoke tests, проверки "дымом") изначально возникли как быстрый способ удостовериться, что самая базовая функциональность системы работает после развертывания или изменения кода. Их идеология — "если что-то критичное сломано, нет смысла запускать подробные проверки". В автоматизации первые smoke-тесты были реализованы как небольшие ручные скрипты для проверки запуска приложения, выхода на логин-экран и базовых действий.

Проблема:

Главные сложности автоматизации smoke-тестов — правильная изоляция минимального набора сценариев, высокая скорость выполнения, минимальная зависимость от нестабильных компонентов (например, сторонних сервисов), а также визуальная и техническая поддержка их "легкости и прозрачности". Если этого не сделать, smoke автоматизация либо становится слишком тяжелой, либо часто дает ложные сработки и требует большого обслуживания.

Решение:

Минимизируйте количество smoke-тестов: в них должны быть только проверки самых критичных "точек входа" (например, авторизация, запуск главного модуля, доступность базы данных).
Выносите нестабильные шаги и внешние зависимости за пределы smoke-сценариев либо стабилизируйте окружения с "заглушками".
Используйте тегирование (@smoke, Suite('smoke') и пр.) и отдельные секции в CI/CD пайплайне, чтобы запускать smoke-тесты всегда первыми.

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

Smoke-сценарии должны выполняться быстро и использовать только самый стабильный кусок инфраструктуры.
Автотесты smoke-класса не должны покрывать UX-детали или сложный workflow.
Smoke-автоматизация требует жесткого контроля за зависимостями и минимального кода поддержки.

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

Можно ли добавлять в smoke-набор сценарии проверки edge-case логики?

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

Нужно ли в smoke-тестах реализовывать многоуровневую обработку ошибок и recovery?

Часто ошибочно считают, что в smoke нужны сложные recovery-механизмы. На самом деле, если smoke-тест падает — это сигнализирует о критической проблеме, которую надо править, а не "обходить" в автотесте.

Должны ли smoke-тесты зависеть от данных, оставленных другими тестами?

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

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

Перегрузка smoke-тестов: слишком много сценариев, превращение их в регрессионные проверки.
Дублирование кода между smoke- и обычными автотестами.
Неявные зависимости: тест использует "грязные" данные/артефакты от других сценариев.

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

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

Сделали в наборе smoke-сценариев 30 разных проверок, часть из них тестирует не только запуск системы, но и сложные алгоритмы, условия edge-case. Выполнение smoke-запуска стало занимать 30 минут, периодически какие-то проверки падали из-за нестабильности бэкенда.

Плюсы:

Легко увидеть узкие места системы.
Высокое покрытие тестами сразу после деплоя.

Минусы:

Потерялась сама суть smoke: "зеленую" сборку можно получить лишь после долгого ожидания и устранения несущественных для вывода системы в прод проблем.
Сложно поддерживать тесты и выделять реальные критические сбои.

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

В smoke-группу вынесли строгий минимум: логин, открытие главной страницы, запрос к базе, базовый API handshake. Smoke-фреймворк работает независимо от основной тестовой матрицы и всегда первым на CI/CD pipeline. Результаты — в отдельном чате и всегда доступны для быстрой диагностики.