Как вы организуете и проводите Smoke-тестирование?

Smoke-тестирование (санитарная проверка, build verification test) — это быстрый набор тестов для проверки работоспособности ключевых функций системы после сборки или деплоя.

Моя практика организации:

1. Цель: Определить, достаточно ли стабильна новая сборка для запуска более глубокого тестирования (регрессионного, интеграционного).
2. Критерии отбора тестов:
   • Проверяют критический путь (core user journey).
   • Минимальны по времени выполнения (обычно 5-15 минут).
   • Высокостабильны и не зависят от нерелевантных данных.
   • Часто включают проверку здоровья системы (health checks).
3. Типичные проверки в Smoke-наборе:
   • Доступность основного URL (frontend и backend API).
   • Успешная аутентификация/авторизация.
   • Работа основных CRUD-операций для ключевых сущностей.
   • Проверка подключения к зависимостям (БД, кэш, внешние сервисы).
4. Автоматизация и интеграция:
   • Автоматизированные сценарии на Postman/Newman (API) и Selenium/Playwright (UI).
   • Интеграция в первый этап CI/CD пайплайна после успешной сборки.

     # Пример этапа в GitLab CI
     smoke-tests:
     stage: test
     script:
     - npm run smoke:api  # Запуск Newman-коллекции
     - npm run smoke:ui   # Запуск набора UI-тестов
     allow_failure: false   # Провал Smoke-тестов блокирует пайплайн

5. Результат: Четкий бинарный ответ — "сборка стабильна" для продолжения тестирования или "требуется фикс" для разработчиков. Это экономит время команды, предотвращая запуск полного регресса на сломанной сборке.