Ответ.

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

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

Проблема:

Основная сложность — ограниченное время и необходимость выбрать действительно важные проверки. Часто тестировщики либо проверяют слишком много (тратят ресурсы зря), либо упускают критичные вещи, из-за чего в релиз могут уйти "дыры".

Решение:

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

- Успешный вход пользователя в систему
- Возможность выполнить основную функцию (например, совершить покупку)
- Проведение оплаты и получение подтверждения

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

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

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

Можно ли считать smoke-тестирование полноценной заменой регрессионного тестирования?

Нет, smoke-тест ориентирован лишь на "работает — не работает" для ключевых функций. Для поиска серьёзных, но неявных багов всегда требуется полноценный регресс.

Что делать, если хотя бы один smoke-тест не пройден? Должно ли тестирование продолжаться?

Нет, дальнейшее тестирование не имеет смысла — команда сообщает о проблеме, релиз блочится, пока баг не исправят.

Должны ли smoke-тесты включать проверки edge-case сценариев?

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

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

Выполнение избыточных тестов, которые не критичны для работоспособности
Отсутствие документации по smoke-тестам (тестировщик "держит всё в голове")
Игнорирование очевидных проблем ради "отчётности"

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

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

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

Плюсы:

Выявили несколько неочевидных багов

Минусы:

Задержка релиза
Потрачены ресурсы и время на малозначимые проверки

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

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