Почему smoke tests должны запускаться на продакшене?
Каждый день на продакшене происходят инциденты: кривая конфигурация Nginx приводит к 502 ошибке, ошибка в миграции БД блокирует запись, утечка памяти превышает лимиты, а сбой CDN отключает статику. Без постоянного мониторинга вы узнаете о проблеме от первого негативного отзыва пользователя — а это уже потерянная выручка и репутация. Мы внедряем дымовые тесты — минимальный набор e2e проверок критических сценариев, которые запускаются каждые 5–15 минут на продакшене. Если что-то сломалось — алерт уходит в Slack или PagerDuty. Команда автоматизирует этот процесс для вашего проекта, сокращая время обнаружения сбоя с 30 минут до 2 минут — проверено на десятках проектов.
Например, на одном из проектов интернет-магазина после деплоя новой версии ORM smoke-тест на страницу списка товаров показал рост времени ответа в 3 раза. Оказалось, что миграция добавила N+1 запрос. Алерт ушёл в Slack, и разработчик откатил изменение за 15 минут, до того как пользователи массово пожаловались на скорость.
Smoke-тесты — первая линия обороны вашего продакшена. Они должны работать 24/7 и сообщать о любых отклонениях немедленно. Определение подхода можно найти в Smoke testing (software).
Какие проблемы решаем?
- N+1 запросы после релиза ORM миграции — smoke-тест на страницу списка товаров покажет рост времени ответа.
- Ошибки авторизации из-за неправильного токена — тест на логин завалится и уведомит администратора.
- Crash формы заказа при изменении frontend-компонентов — smoke-тест на checkout обнаружит пропажу кнопки.
- Падение API health endpoint после деплоя бэкенда — отдельный тест проверяет ответ /api/health.
- Потеря ключевого элемента в DOM после обновления CSS-фреймворка.
Как мы выбираем инструмент: таблица сравнения
| Инструмент | Время прогона | Поддержка браузеров | Отладка | CI интеграция | Рекомендация |
|---|---|---|---|---|---|
| Playwright | 1–3 мин | Chromium, Firefox, WebKit | Trace viewer, ожидание автоматическое | GitHub Actions, GitLab, Jenkins | Для большинства проектов |
| Cypress | 2–5 мин | Только Chromium | Dashboard, time travel | CI через cypress run | Приложения React/Vue |
| k6 browser | 1–2 мин | Chromium (Chrome) | Совместно с k6 metrics | Не требует отдельного CI | Уже есть k6 для нагрузки |
На практике мы используем Playwright — он надёжнее Selenium, современный API, встроенная поддержка сетевых моков и trace viewer для отладки. Пример кода ниже.
Как мы это делаем: реальный кейс
Проект: интернет-магазин на Next.js + Laravel, 10k товаров, нагрузка 1000 запросов/мин. Задача: настроить smoke-тесты для корзины, оформления заказа, поиска и API health. Что сделали:
- Выделили critical happy paths: главная → поиск → карточка товара → корзина → оформление → логин (если не залогинен) → оплата mock.
- Написали 8 тестов на Playwright (TypeScript).
- Настроили расписание GitHub Actions каждые 10 минут с повторной попыткой 2 раза.
- Создали smoke-test пользователя с флагом is_synthetic: true в БД и минимальными правами.
- Организовали уведомления в Slack через webhook при падении.
Результат: среднее время обнаружения сбоя снизилось с 30 минут до 2 минут. За месяц smoke-тесты предотвратили 5 инцидентов, которые могли вызвать потерю выручки.
Как выглядит типовое внедрение?
- Аналитика: вместе с вами определяем критические сценарии, которые должны быть доступны всегда. Составляем матрицу покрытия.
- Проектирование: выбираем инструмент (Playwright/Cypress/k6), проектируем архитектуру тестов, настраиваем окружение и секреты.
- Реализация: пишем дымовые тесты, настраиваем конфигурацию (reporter, retries, workers).
- Тест на staging: прогоняем тесты на staging-окружении, проверяем, что они не ломают реальный трафик.
- Деплой на продакшен: настраиваем cron-расписание в CI (GitHub Actions/GitLab), подключаем алерты.
- Сопровождение: 2 недели поддержки: мониторим отклонения, корректируем тесты под новые релизы.
Сроки и что входит в работу
| Этап | Срок | Что входит |
|---|---|---|
| Написание 5–10 smoke-тестов | 2–3 дня | Тесты для critical happy paths, конфигурация Playwright, репортеры |
| Настройка CI и алертов | 1 день | GitHub Actions workflow, Slack/PagerDuty webhook, дашборд статуса |
| Создание тестовой учётной записи | 0,5 дня | Smoke-test пользователь, флаг is_synthetic, ротация пароля в secrets |
| Итого | 3–5 дней | Документация (архитектура, список сценариев), настройка метрик, обучение команды |
Точные сроки рассчитываем после анализа вашего приложения. Каждый проект уникален.
Наш опыт
Более 7 лет мы автоматизируем тестирование, выполнили 10+ успешных проектов для e-commerce. Инженеры сертифицированы по Playwright и Kubernetes. Предоставляем гарантию 3 месяца на стабильную работу внедрённых тестов: если smoke-тест ложно падает из-за изменений в приложении — бесплатно адаптируем его. Наши решения используют в компаниях из топ-10 e-commerce России и Беларуси.
Как начать?
Свяжитесь с нами, чтобы мы проанализировали ваши критические сценарии. Закажите пилотный проект — за 2 недели мы внедрим smoke-мониторинг и настроим алерты. Оценим объём работы бесплатно.