Розробка E2E димових тестів для моніторингу продакшену
Чому smoke тести повинні запускатися на продакшені?
Щодня на продакшені трапляються інциденти: крива конфігурація 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 для налагодження. Приклад коду нижче.
npx playwright test Як ми це робимо: реальний кейс
Проект: інтернет-магазин на 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-моніторинг та налаштуємо алерти. Оцінимо обсяг роботи безкоштовно.