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

🔧 Суть Smoke-тестирования

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

• новой сборки (build),

• слияния кода (merge),

• обновления зависимостей (dependencies),

• интеграции нового модуля.

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

🧪 Что включает в себя Smoke-тест

Конкретное наполнение зависит от типа продукта, но типичные проверки включают:

• Запускается ли приложение?

• Отображаются ли ключевые страницы (главная, логин, дашборд)?

• Работает ли процесс логина/регистрации?

• Выполняются ли основные действия (например, оформление заказа, отправка формы)?

• Есть ли доступ к базе данных и API?

• Подгружаются ли статические ресурсы (CSS, JS, изображения)?

• Нет ли фатальных ошибок в консоли или логах?

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

🧭 Где и когда используется Smoke-тестирование

1. После каждой новой сборки

Как только разработчик или CI/CD-сервер создал новую версию приложения, запускается smoke-тест, чтобы убедиться, что сборка жизнеспособна и её вообще можно тестировать дальше.

2. Перед регрессионным тестированием

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

3. После деплоя на тестовый или продакшн-сервер

Позволяет сразу проверить, не сломалось ли что-то критически важное после выкатки.

4. На этапе Continuous Integration

Входит в автоматический pipeline CI/CD — если smoke-тест не пройден, pipeline прерывается, и дальнейшие действия (тесты, деплой) не происходят.

🏗 Примеры сценариев Smoke-тестов

Для веб-приложения интернет-магазина:

• Открывается главная страница?

• Можно зайти под существующим пользователем?

• Работает поиск по товарам?

• Добавляется товар в корзину?

• Открывается форма оплаты?

Для мобильного приложения:

• Устанавливается ли приложение?

• Запускается ли без ошибок?

• Подгружается ли стартовый экран?

• Работает ли вход через OAuth?

• Открываются ли основные разделы (каталог, корзина)?

🚀 Преимущества Smoke-тестирования

1. **Быстрая проверка жизнеспособности продукта.
   **
2. **Раннее обнаружение критических дефектов.
   **
3. **Экономия времени QA-команды — не тратится ресурс на тестирование “мертвых” сборок.
   **
4. **Поддержка стабильности в CI/CD.
   **
5. **Повышение качества релизов.
   **

🛠 Отличие Smoke от Sanity-тестирования

Иногда термины smoke testing и sanity testing используются как синонимы, но строго говоря, между ними есть различие:

Критерий	Smoke Testing	Sanity Testing
Цель	Проверить, можно ли продолжать тестирование	Проверить, что конкретная ошибка исправлена
---	---	---
Глубина	Поверхностная	Узконаправленная и точечная
---	---	---
Охват	Вся система	Только затронутый модуль
---	---	---
Пример	Работает ли вход в систему	Исправилась ли ошибка при сбросе пароля
---	---	---
Время проведения	После сборки	После фикса багов или мелкой доработки
---	---	---

🔄 Автоматизация Smoke-тестов

Smoke-тестирование — частый кандидат для автоматизации, поскольку:

• выполняется часто (каждая сборка),

• содержит повторяющиеся шаги,

• имеет стабильные сценарии.

Для автоматизации используются инструменты и фреймворки:

• Selenium, Cypress (веб),

• Appium (мобильные приложения),

• PyTest, JUnit, TestNG, Mocha (бэкенд или API),

• Postman / Newman (для проверки API).

Обычно smoke-тесты выделяются в отдельную тестовую группу или тег (@smoke) и запускаются как первая стадия CI.

⚠️ Риски и ограничения

• Smoke-тесты не выявляют всех ошибок — они только фильтруют критические сбои.

• Переусложнённые smoke-тесты теряют смысл — они должны быть минимальными.

• Smoke-тест не заменяет полноценное тестирование (ни регрессионное, ни юнит-тесты).

Smoke-тестирование — это первый "щит" качества, защищающий процесс разработки от потерь времени и ресурсов при работе с нестабильными сборками. Оно особенно критично в Agile и DevOps-процессах, где скорость и стабильность сборок играют ключевую роль.