Был ли Smoke на проекте

Ответ на вопрос о Smoke-тестировании на проекте

Да, Smoke-тестирование (или Sanity-проверка) было обязательной и критически важной частью нашего процесса тестирования на всех проектах, где я работал. Мы рассматривали его не просто как "быструю проверку", а как фундаментальный защитный механизм, предотвращающий потерю времени команды на нестабильные сборки и позволяющий сосредоточиться на глубоком тестировании только работоспособных версий продукта.

Цели и место Smoke-теста в нашем процессе

Основные цели, которые мы преследовали:

• Быстрая валидация стабильности сборки (build) после развертывания на тестовом стенде или в среде непрерывной интеграции (CI).
• Подтверждение, что ключевые, самые важные функции приложения ("happy path") работают после внесения изменений.
• Принятие решения о целесообразности запуска полного цикла регрессионного, интеграционного или функционального тестирования. Если Smoke-тест падает, сборка отвергалась, и QA не приступали к дальнейшему тестированию, экономя десятки человеко-часов.

В нашей DevOps-цепочке (CI/CD) Smoke-тесты запускались автоматически сразу после успешного развертывания каждой новой сборки на тестовом окружении.

Содержание и инструментарий Smoke-тест кейсов

Набор для Smoke-тестирования был небольшим (обычно 10-30 кейсов), но покрывал ядро бизнес-логики. Например, для e-commerce проекта:

1. Загрузка главной страницы и каталога товаров.
2. Поиск товара.
3. Добавление товара в корзину (для авторизованного и неавторизованного пользователя).
4. Прохождение ключевых шагов оформления заказа (до оплаты).
5. Вход в систему под существующим пользователем.
6. Проверка ответа основных API-эндпоинтов (например, получение профиля, списка товаров).

Мы стремились к максимальной автоматизации этих проверок. Использовался Python + pytest как основной стек для API-тестов и Playwright для UI-проверок. Автоматизированные Smoke-тесты были быстрыми и позволяли получить результат за 3-5 минут.

Пример автоматизированного Smoke-теста для API на Python (pytest):

import pytest
import requests

BASE_URL = "https://api.example.com/v1"

def test_smoke_health_check():
    """Проверка доступности основного эндпоинта."""
    response = requests.get(f"{BASE_URL}/health")
    assert response.status_code == 200
    assert response.json()["status"] == "OK"

def test_smoke_core_feature_auth():
    """Smoke: Проверка базового потока авторизации."""
    auth_payload = {"username": "test_user", "password": "test_pass"}
    response = requests.post(f"{BASE_URL}/auth/login", json=auth_payload)

    assert response.status_code == 200
    json_data = response.json()
    assert "access_token" in json_data
    assert json_data["token_type"] == "Bearer"

def test_smoke_core_feature_get_data():
    """Smoke: Получение основных данных после аутентификации."""
    # Получаем токен (можно вынести в фикстуру)
    auth_payload = {"username": "test_user", "password": "test_pass"}
    auth_response = requests.post(f"{BASE_URL}/auth/login", json=auth_payload)
    token = auth_response.json()["access_token"]

    headers = {"Authorization": f"Bearer {token}"}
    response = requests.get(f"{BASE_URL}/users/me", headers=headers)

    assert response.status_code == 200
    assert response.json()["username"] == "test_user"

Пример конфигурации запуска в CI (GitLab CI):

stages:
  - deploy_to_staging
  - smoke_tests

smoke_test:
  stage: smoke_tests
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest tests/smoke/ --alluredir=./allure-results
  artifacts:
    when: always
    paths:
      - ./allure-results/
  only:
    - main
    - merge_requests

Результаты и действия при падении Smoke-теста

Результат Smoke-прогона был бинарным: PASS или FAIL. В случае FAIL:

1. Сборка автоматически помечалась как нестабильная в CI-системе (Jenkins/GitLab).
2. Уведомление отправлялось в Slack-чат команды разработки и тестирования с указанием упавших тестов и ссылкой на сборку.
3. QA-команда приостанавливала планируемое тестирование новой функциональности для этой сборки.
4. Разработчики получали высший приоритет на исправление причины падения Smoke-теста, так как это блокировало весь процесс.

Вывод

Smoke-тестирование было для нас "воротом качества". Это эффективная практика, которая обеспечивала базовую стабильность продукта, повышала предсказуемость процессов и напрямую влияла на скорость разработки, предотвращая тестирование на заведомо сломанных сборках. Его наличие — признак зрелого и отлаженного процесса разработки.