Какие проверки включить в смоук-тестирование сайта?
Что проверяют
Понимаете ли вы, что смоук это быстрая проверка «сборка жива, её можно тестировать дальше», а не урезанная регрессия. Следом спрашивают, сколько он должен длиться и что вы делаете, если он упал.
Как отвечать
Сначала критерий отбора: в смоук идёт только то, без чего остальное тестирование бессмысленно, плюс главный путь пользователя. Вручную это около получаса, в автоматизации несколько минут. Прогон после каждого деплоя на каждый стенд.
Проверки:
- доступность: главная и ключевые разделы отвечают 200, сертификат HTTPS валиден, нет циклов редиректов, несуществующий адрес отдаёт 404;
- версия: на стенде именно та сборка, которую вы ждёте. Помогает номер версии в футере или эндпоинт
/health; - ресурсы: стили и скрипты загрузились, во вкладке Network нет 404 и 500, в консоли нет ошибок;
- вход: логин тестовым пользователем и выход, регистрация, если она ключевая для продукта;
- главный сценарий: для магазина это поиск, карточка товара, корзина и оформление до оплаты в тестовом режиме платёжки;
- ключевая форма: заявка отправляется и доходит до адресата, на почту или в CRM;
- критичные интеграции: только те, без которых продукт не работает, например оплата.
Отдельно скажите, чего в смоуке нет: полной кроссбраузерности, нагрузочных тестов, проверок валидации каждого поля. Это регрессия и отдельные виды тестирования.
Про автоматизацию: набор тестов с тегом @smoke в Playwright или Cypress, который CI запускает сразу после деплоя. Упал смоук, значит сборку возвращают разработчикам и дальше не тестируют.
Где спотыкаются
Тащат в смоук всё подряд, и он превращается в трёхчасовую регрессию, которую никто не хочет запускать после каждого деплоя.
Путают смоук и санити. Санити это узкая проверка конкретного исправления или фичи после изменения, а смоук поверхностно проверяет всю сборку.
Ограничиваются «страница открывается». Главная отвечает 200, оформление заказа сломано, а смоук при этом зелёный.