Что такое smoke-тестирование?

Smoke-тестирование (дымовое тестирование), также известное как Build Verification Testing (BVT) — быстрый и широкий тест наиболее критической функциональности для определения, достаточно ли стабильна новая сборка для дальнейшего тестирования. Название пришло из тестирования оборудования — при включении новой платы сначала проверяют, не идёт ли дым. Если идёт, нет смысла тестировать что-либо ещё.

В ПО smoke-тестирование отвечает на один вопрос: «Эта сборка принципиально сломана, или можно переходить к более глубокому тестированию?»

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

Smoke vs другие быстрые тесты

ТипЦельМасштабКогда
SmokeСборка стабильна?Широкий, но поверхностныйПосле каждой сборки
SanityИсправление работает?Узкий и сфокусированныйПосле конкретных изменений
РегрессияЧто-то сломалось?КомплексныйПеред релизом

Что включать в smoke-suite

Smoke-suite должна быть:

  • Маленькой: 5-20 тест-кейсов
  • Быстрой: Завершение за 10 минут
  • Критичной: Только самая важная функциональность
  • Автоматизированной: Запуск без человеческого вмешательства

Smoke-тесты для веб-приложений

  1. Приложение загружается — Главная возвращает HTTP 200, рендерится корректно
  2. Вход работает — Пользователь аутентифицируется с валидными данными
  3. Навигация работает — Все основные пункты меню доступны
  4. Основная функция 1 — Главная бизнес-функция работает (поиск даёт результаты)
  5. Основная функция 2 — Вторая бизнес-функция работает (добавление в корзину)
  6. Подключение к БД — Приложение читает и пишет в базу
  7. Статические ресурсы — CSS, JavaScript и изображения загружаются
  8. Обработка ошибок — Корректная страница 404 (не стек-трейс)

Smoke-тесты для мобильных приложений

  1. Приложение запускается — Открывается без сбоев
  2. Вход — Пользователь может войти
  3. Главный экран — Основной контент отображается
  4. Навигация — Tab bar / drawer работает
  5. Сетевые запросы — API-вызовы успешны, данные загружаются
  6. Push-уведомления — Регистрация успешна
  7. Основное действие — Главное действие пользователя завершается

Smoke-тесты для API

  1. Health-эндпоинт — GET /health возвращает 200
  2. Аутентификация — Валидный токен → 200; невалидный → 401
  3. Основной GET — Главная операция чтения возвращает ожидаемую структуру
  4. Основной POST — Главная операция записи создаёт ресурс
  5. Операции с БД — CRUD завершается без ошибок
  6. Внешние интеграции — Соединения со сторонними сервисами активны
  7. Формат ответа — API возвращает корректный JSON/XML

Smoke-тесты в CI/CD

Автоматизированные smoke-тесты — первые ворота качества в CI/CD пайплайне:

graph LR CODE[Коммит кода] --> BUILD[Сборка] BUILD --> SMOKE[Smoke-тесты] SMOKE -->|Прошли| UNIT[Unit-тесты] UNIT --> INT[Интеграционные] INT --> DEPLOY[Deploy в Staging] DEPLOY --> E2E[E2E тесты] SMOKE -->|Упали| REJECT[Отклонить сборку
Уведомить разработчика] style SMOKE fill:#eab308,color:#000 style REJECT fill:#ef4444,color:#000

Лучшие практики:

  • Запускать на каждой сборке, не только ночью
  • Держать быстрыми (менее 10 минут)
  • Никогда не пропускать
  • Агрессивно поддерживать — нестабильные тесты исправлять немедленно

Упражнение: Создайте чек-лист smoke-тестов для веб-приложения

Вы QA Lead для приложения управления проектами (аналог Jira/Asana):

  • Аутентификация (email/пароль и SSO)
  • Создание и управление проектами
  • Создание задач с исполнителями, сроками, приоритетами
  • Kanban-доска с drag-and-drop
  • Вложения файлов в задачи
  • Уведомления (в приложении и по email)
  • Дашборд отчётов с графиками
  • Поиск по проектам и задачам

Создайте чек-лист из 10-15 smoke-тестов. Для каждого: название, шаги, ожидаемый результат.

ПодсказкаФокусируйтесь на happy path критических сценариев. Спросите: «Если эта функция сломается, приложение станет бесполезным?» Если да — это smoke-тест. Если просто неприятно, но работает — это регрессия.
Решение

Приоритет 1: Приложение работает

  1. Главная загружается — Перейти по URL → Страница входа рендерится, HTTP 200
  2. Вход по email — Валидные данные → Дашборд загружается
  3. Вход через SSO — Нажать «Войти через Google» → Дашборд загружается

Приоритет 2: Основные функции 4. Создание проекта — «Новый проект» → Имя → Сохранить → Появляется в списке 5. Создание задачи — Открыть проект → «Новая задача» → Заголовок, исполнитель, срок → Появляется на Kanban 6. Kanban загружается — Открыть доску с задачами → Колонки и карточки корректны 7. Поиск работает — Поиск «Smoke Test» → Результаты включают созданный проект/задачу

Приоритет 3: Поддерживающие функции 8. Загрузка файла — Открыть задачу → Прикрепить файл → Появляется в списке 9. Уведомления — Назначить задачу другому → Уведомление появляется 10. Дашборд с данными — Перейти к отчётам → Графики рендерятся

Приоритет 4: Обработка ошибок 11. Выход работает — Меню профиля → «Выйти» → Перенаправление на вход 12. Страница 404 — Невалидный URL → Кастомная 404 (не ошибка сервера) 13. Ошибки API — Доступ к несуществующему проекту → «Не найдено»

Итого: 13 smoke-тестов, время: 8-10 мин (автоматизированные), 15-20 мин (ручные)

Антипаттерны smoke-тестирования

Антипаттерн 1: Слишком много тестов. 100 тестов за час — это регрессионная suite, притворяющаяся smoke. Держите под 20.

Антипаттерн 2: Тесты, которые никогда не падают. Если не ловили сломанную сборку за год — возможно, тестируют не то.

Антипаттерн 3: Только ручные. Ручные smoke лучше, чем ничего, но медленные и непоследовательные. Автоматизируйте.

Антипаттерн 4: Игнорирование сбоев. «Этот тест всегда падает по понедельникам» — признак глубокой проблемы. Каждый сбой расследуйте.

Профессиональные советы

Совет 1: Smoke-тест = ваша уверенность в развёртывании. Если бы не развернули в продакшен после прохождения smoke — тест неполный.

Совет 2: Не только для QA. Разработчики должны запускать локально перед пушем. Это ловит сломанные сборки до CI.

Совет 3: Включайте проверки инфраструктуры. БД упала, CDN настроен неправильно, SSL-сертификат просрочен — добавьте базовые health checks.

Ключевые выводы

  • Smoke-тестирование — быстрая широкая проверка стабильности сборки
  • Только критическая функциональность (5-20 тестов, до 10 минут)
  • Автоматизация и интеграция в CI/CD как первые ворота качества
  • Запуск на каждой сборке — страховочная сетка от сломанных развёртываний
  • Разным приложениям нужен разный состав smoke-тестов
  • Агрессивная поддержка — нестабильные или игнорируемые тесты хуже отсутствия