Сборка проходит небольшой набор критических проверок до запуска полного цикла. Объясните механизм smoke-тестирования и критерий, по которому сборку допускают дальше.
Smoke-тестирование — это быстрый широкий набор проверок, который определяет, пригодна ли сборка для дальнейшего тестирования. Проверяют не все детали, а доступность и работоспособность ключевых функций: запуск приложения, авторизацию, основные переходы и критический пользовательский сценарий.
Если критическая проверка не проходит, сборку обычно не передают в полный цикл: детальное тестирование на ней даст много вторичных ошибок и затратит время. Допуск означает не отсутствие дефектов, а достаточную тестопригодность сборки.
Подход появился как практический способ быстро отсеивать явно неработоспособные сборки до дорогих и длительных проверок. Полный набор тестов имеет смысл только тогда, когда приложение запускается и его базовые подсистемы доступны.
Название связано с идеей поверхностной проверки наиболее важных свойств, а не с исчерпывающим анализом продукта. Это не замена функциональному, регрессионному или интеграционному тестированию, а фильтр перед ними.
Новая сборка может формально содержать исправление нужного дефекта, но при этом не запускаться, не принимать пользователя или не выполнять основной сценарий. Если сразу начать полный тестовый прогон, значительная часть результатов будет непригодна для анализа.
Так возникают каскадные ошибки: недоступный сервис вызывает сбои авторизации, оформления заказа и проверки истории операций. Команда тратит время на симптомы, хотя первичная проблема находится на уровне готовности сборки.
Слишком слабый набор smoke-проверок создаёт ложное ощущение пригодности. Слишком большой набор превращает smoke-тестирование в сокращённую регрессию и уменьшает его главное преимущество — скорость обратной связи.
Набор формируют вокруг критических рисков и минимального бизнес-потока. Для каждого теста задают ожидаемый результат, который подтверждает, что соответствующая часть системы доступна: приложение стартует, тестовый пользователь может войти, данные загружаются, а ключевая операция завершается хотя бы на базовом уровне.
Smoke-тесты должны быть быстрыми, стабильными и давать однозначный сигнал. Их цель — ответить на вопрос «можно ли продолжать тестирование этой сборки», а не определить полноту покрытия требований.
Обычно действует правило: провал критической проверки блокирует дальнейший полный прогон или переводит сборку на исправление. Некритичный дефект может не блокировать тестирование, если заранее определены критерии его влияния и риска.
Набор пересматривают при изменении архитектуры, ключевых пользовательских потоков и рисков продукта. Автоматизация полезна для частого запуска, но не делает неудачный набор качественным: автоматизированные проверки тоже могут быть нестабильными, избыточными или слишком узкими.
Главный компромисс — между скоростью и глубиной. Чем больше сценариев включено, тем выше вероятность обнаружить серьёзную проблему, но тем дольше обратная связь и тем дороже сопровождение. Поэтому в smoke-набор включают не самые простые тесты, а самые важные признаки работоспособности продукта.
После выпуска сборки команда обнаружила, что приложение открывается, но авторизация через основной провайдер недоступна. Рассматривались три варианта: сразу запускать полную регрессию, ограничиться проверкой запуска или выполнить короткий smoke-набор с авторизацией и базовым пользовательским потоком.
Полная регрессия дала бы много связанных ошибок и затянула бы диагностику. Проверка только запуска была бы слишком слабой: она не выявляла проблему, блокирующую большинство сценариев. Команда выбрала короткий набор с авторизацией, чтением данных и выполнением основной операции.
Сборку не допустили до полного цикла, а дефект передали на исправление. После устранения проблемы smoke-набор прошёл, и регрессию запустили на сборке, пригодной для содержательного анализа.
1. Чем smoke-тестирование отличается от sanity-тестирования после небольшого исправления?
Smoke-тестирование оценивает общую пригодность сборки и охватывает несколько критических областей. Sanity-тестирование обычно является более узкой проверкой изменённой функциональности и ближайших зависимостей после конкретного изменения.
Границы терминов могут отличаться в командах, поэтому важнее зафиксированный в проекте смысл. Ключевое различие — smoke отвечает за общий сигнал о жизнеспособности сборки, а sanity — за разумность продолжения проверки конкретного изменения.
2. Должен ли любой провал smoke-теста автоматически блокировать сборку?
Не обязательно. Блокирующим должен быть провал, который означает недоступность критической функции или делает результаты дальнейших тестов недостоверными.
Например, временная проблема в второстепенном отчёте может не препятствовать проверке оформления заказа, если это разрешено критериями команды. Такое исключение должно быть явным и основанным на риске, иначе решение о допуске станет субъективным.
3. Может ли успешный smoke-прогон быть основанием для выпуска продукта?
Нет. Успешный smoke-прогон подтверждает только минимальную работоспособность основных путей и пригодность сборки для дальнейшего тестирования.
Он не доказывает корректность всех функций, отсутствие дефектов, достаточную производительность, безопасность или соответствие требованиям. Решение о выпуске требует других свидетельств: результатов функционального и регрессионного тестирования, оценки рисков и выполнения критериев готовности.