В мире тестирования существует золотое правило: не трать время на полную проверку, пока не убедился, что продукт вообще работает. Именно для этого придумано smoke-тестирование — первый рубеж QA-защиты от тотального фиаско.
Разберёмся, что это такое, почему оно называется "дымовым", чем отличается от sanity и как настроить грамотный smoke-чек-лист.
Что такое smoke-тестирование?
Smoke-тестирование (или "дымовое") — это поверхностная проверка базовой работоспособности системы после сборки. Если на этом этапе всё падает, дальше тестировать бессмысленно. Это как проверить, заводится ли машина, прежде чем ехать на техосмотр.
Термин пришёл из железа: инженеры включали устройство и смотрели — идёт ли дым. Если идёт, значит, что-то не так, и дальше копать смысла нет.
В софте это выглядит так:
- Загружается ли приложение
- Можно ли авторизоваться
- Открываются ли ключевые страницы
- Работают ли основные функции (создать заказ, отправить сообщение и т.д.)
Smoke-тест отвечает на главный вопрос: имеет ли смысл проводить дальнейшее тестирование?
Зачем нужно smoke-тестирование?
Вот типичная ситуация:
- Разработчик пушит изменения
- Вы получаете новую сборку
- Начинаете полную регрессию
- Через 10 минут всё валится с 500 ошибками
А если бы кто-то проверил основные функции в начале, сэкономилось бы кучу времени.
Smoke-тестирование нужно, чтобы:
- Быстро понять, пригодна ли сборка для тестов
- Сэкономить ресурсы команды
- Избежать ложных баг-репортов, вызванных критическими сбоями
- Дать быструю обратную связь разработчикам
Проще говоря: smoke-тест — это фильтр мусора на входе в QA-процесс.
Чем отличается smoke от sanity?
Многие путают smoke и sanity. Давай разберём по-простому:
Smoke = жив ли продукт вообще?
Sanity = не сломалось ли то, что чинили?
Что входит в smoke-тест?
Список зависит от продукта, но обычно включает:
1. Запуск приложения / сайта
- Загружается ли страница?
- Нет ли критических ошибок в консоли?
2. Авторизация / регистрация
- Можно ли войти с валидным логином?
- Обрабатываются ли ошибки при неправильных данных?
3. Главная навигация
- Переходы по ключевым разделам (профиль, корзина, поиск и т.д.)
4. Ключевой функционал
- Создание заказа
- Публикация поста
- Отправка формы обратной связи
5. Выход из аккаунта
- Кнопка "Выйти" работает корректно
6. Минимальная проверка отображения интерфейса
- Кнопки видны, поля не съехали, тексты читаемы
Важно: smoke-тест не должен проверять бизнес-логику, пограничные случаи или сложные сценарии. Это экспресс-проверка на жизнеспособность.
Как организовать smoke-тестирование
1. Создай отдельный smoke-чек-лист
Это не должно быть 100+ пунктов. В идеале — до 20 простых проверок. Лучше всего — автоматизированных.
Пример чек-листа:
- Открывается главная страница
- Можно залогиниться
- Открывается личный кабинет
- Работает поиск
- Можно добавить товар в корзину
- Открывается страница оформления заказа
2. Запускай smoke после каждой новой сборки
Именно он показывает, можно ли вообще дальше тестировать. Лучше потратить 10 минут на smoke, чем 2 часа на регрессию, которая обрывается на первом шаге.
3. Используй автоматизацию
Автоматизированные smoke-тесты — это мечта любого QA. Они запускаются автоматически при каждой сборке и сразу говорят: всё упало или можно жить.
Если автоматизация пока не внедрена — пиши чек-лист и проверяй руками.
4. Документируй результаты
Даже если всё прошло успешно — фиксируй. Это поможет отследить стабильность сборок и коммуникацию с разработкой.
Ошибки при проведении smoke-тестов
1. Превращение smoke в мини-регрессию
Smoke — это не время для глубоких проверок. Не надо расписывать каждый сценарий. Быстро, по верхам.
2. Отсутствие чек-листа
Без списка можно что-то забыть. И внезапно — не протестирована авторизация, а завтра релиз.
3. Проведение smoke после полной проверки
Тут всё наоборот. Сначала smoke. Если он не прошёл — никуда дальше не идём.
4. Игнорирование результатов
Не прошёл smoke? Остановись. Не надо багать всё подряд. Сообщи команде, разберитесь, и только потом продолжай.
Пример отчёта о smoke-тестировании
Сборка: staging.site.com, билд #2578
Дата: 29.07.2025
Ответственный: QA Ivan
Smoke-чек-лист:
- Приложение запускается
- Авторизация проходит успешно
- Открывается раздел «Профиль»
- Можно добавить товар в корзину
- Страница оформления заказа — ошибка 500
Итог: Smoke-тест не пройден. Блокер на оформлении заказа. Тестирование остановлено, баг #983 заведён в Jira. Сообщено разработке.
Что делать, если smoke не пройден?
- Не продолжай тестирование — это трата времени
- Заведи баг с меткой Blocker или Critical
- Сообщи команде — желательно в канал или тикет
- Жди фикса и после — перезапусти smoke-тест
Итоги
Smoke-тестирование — это фильтр здравого смысла в QA. Оно позволяет:
- Не тратить время на мёртвые сборки
- Быстро давать обратную связь
- Сохранять нервы команде
Помни: не надо быть супергероем, чтобы найти баг. Достаточно просто вовремя заметить, что сайт вообще не работает.
Бонус: шаблон smoke-чек-листа (универсальный)
- Приложение / сайт загружается
- Авторизация валидная / невалидная работает корректно
- Главная страница доступна
- Навигация между ключевыми разделами работает
- Создание объекта (пост/заказ/форма) работает
- Нет критических ошибок в консоли
- Выход из аккаунта работает
Хочешь больше статей по теме? Подписывайся на канал, где баги — это не кошмар, а любимая игра.