Сколько раз использовал Smoke на проекте?

Мой опыт применения Smoke-тестирования на проектах

Говоря о Smoke-тестировании (также известном как Sanity Check или Build Verification Testing), я применял его на абсолютно каждом проекте, где была внедрена более-менее формализованная процессная модель разработки. Если говорить о количестве "раз" — это каждая сборка (build) или каждый деплой на тестовые среды, что может исчисляться сотнями и тысячами запусков в год на крупном проекте.

Ключевые сценарии применения Smoke-наборов

• После сборки/деплоя: Основной кейс. После развертывания новой версии приложения на тестовый стенд автоматически или вручную запускается smoke-сuite для проверки, что "система не дымится" — ключевые функции работают, нет критических падений на старте.
• Перед передачей на регрессионное тестирование: Smoke-тесты выступают фильтром. Если сборка не проходит smoke — её нет смысла отдавать тестировщикам на глубокую проверку, это экономит время команды.
• При приемке фич от разработки: Перед тем как взять задачу в тестирование, я запускаю минимальный smoke-набор, связанный с измененным модулем, чтобы убедиться в его базовой работоспособности.
• В процессе ежедневной работы: Для быстрой проверки состояния тестовой среды после возможных сбоев или вмешательств администраторов.

Эволюция подхода: от рутины к критически важному процессу

Раньше, на небольших проектах, smoke-чек мог представлять собой ручной чек-лист из 10-15 пунктов, который тестировщик проходил перед началом работы. Со временем это превратилось в автоматизированные наборы, интегрированные в CI/CD пайплайн.

Пример упрощенного сценария smoke-теста для веб-приложения в контексте CI:

# Пример шага в GitLab CI / GitHub Actions
smoke_test:
  stage: test
  script:
    - echo "Запуск Smoke-тестов после деплоя на staging..."
    - npm run smoke-tests
  rules:
    - if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop"

А так может выглядеть один из тестов на Jest + Playwright:

// smoke.test.js
import { test, expect } from '@playwright/test';

test('SMOKE: Главная страница загружается и содержит ключевые элементы', async ({ page }) => {
  // 1. Проверка доступности основного URL
  await page.goto(process.env.BASE_URL);
  await expect(page).toHaveTitle(/МоеПриложение/);

  // 2. Проверка, что ключевые элементы отрендерены (не упал JS)
  await expect(page.locator('nav')).toBeVisible();
  await expect(page.getByRole('heading', { name: 'Добро пожаловать' })).toBeVisible();
  await expect(page.getByRole('button', { name: 'Войти' })).toBeEnabled();

  // 3. Быстрая проверка критического API-эндпоинта
  const apiResponse = await page.request.get('/api/health');
  expect(apiResponse.ok()).toBeTruthy();
});

Какие проблемы решает регулярное применение Smoke-тестов:

1. Раннее обнаружение блокеров: Нет ничего хуже, когда вся команда тестирования тратит день на сборку, которая не работает из-за очевидной ошибки деплоя или миграции БД.
2. Сохранение времени и ресурсов: Экономия 2-3 часов работы нескольких тестировщиков на каждой "битой" сборке дает огромный эффект в масштабе года.
3. Повышение стабильности процесса: Smoke-тесты — это "сторожевой пес" целостности системы. Они дают быструю обратную связь разработке о состоянии сборки.
4. Документирование базовой работоспособности: Набор smoke-тестов по сути является живой документацией того, что считается минимально работоспособным продуктом.

Итог: Smoke-тестирование для меня — это не эпизодическая практика, а базовая гигиена процесса обеспечения качества, такая же обязательная, как и ведение баг-трекера. Его использование носит систематический, а не количественный характер. На зрелых проектах с CI/CD оно выполняется несколько раз в день автоматически и является неотъемлемым "зеленым шлюзом" для продвижения сборки по pipeline.