Как выбирал задачи для Smoke

Стратегия выбора сценариев для Smoke-тестирования

Выбор задач для Smoke-тестирования — это критически важный процесс, напрямую влияющий на эффективность контроля базовой работоспособности системы. На практике я формирую smoke-сценарии по принципу «максимум покрытия критического функционала при минимальном времени выполнения». Вот мой алгоритм:

1. Ключевые критерии отбора

• Бизнес-критические пути (Happy Path): Всегда включаю основные пользовательские сценарии, без которых продукт теряет ценность. Например, для интернет-магазина: вход в аккаунт, просмотр каталога, добавление товара в корзину, оформление заказа, оплата.
• Функциональность ядра системы: Тестирование интеграций, без которых система не работает — база данных, аутентификация, платежный шлюз, основные API-эндпоинты.
• Области, затронутые последними изменениями: Анализирую diff коммитов в репозитории и задачи в Jira. Если в спринте меняли модуль оплаты, smoke-сценарии для этого модуля становятся приоритетными.
• Исторически «хрупкие» модули: Использую данные из баг-трекера (например, JIRA). Модули с наибольшим количеством регрессионных багов в прошлом обязательно попадают в smoke.
• Инфраструктура и конфигурация: Проверка доступности сервисов, корректности настроек конфигурационных файлов после деплоя.

2. Практическая реализация (на примере веб-приложения)

Я создаю и поддерживаю динамический чек-лист или набор автотестов. Вот концептуальный пример на Python + pytest/Selenium, который отражает логику:

import pytest
from selenium import webdriver

class TestSmokeSuite:
    """Набор smoke-тестов для веб-приложения электронной коммерции."""

    @pytest.fixture(scope="class")
    def setup(self):
        driver = webdriver.Chrome()
        driver.implicitly_wait(10)
        yield driver
        driver.quit()

    def test_user_login(self, setup):
        """TC-SMOKE-01: Критический путь - аутентификация пользователя."""
        driver = setup
        driver.get("https://app.baseurl/login")
        driver.find_element("id", "email").send_keys("valid_user@test.com")
        driver.find_element("id", "password").send_keys("valid_pass")
        driver.find_element("xpath", "//button[@type='submit']").click()
        assert "Личный кабинет" in driver.page_source
        print("✅ Базовая аутентификация работает")

    def test_main_page_loading(self, setup):
        """TC-SMOKE-02: Доступность главной страницы и ключевых элементов."""
        driver = setup
        driver.get("https://app.baseurl/")
        assert driver.title == "Онлайн-магазин"
        assert driver.find_element("id", "search-box").is_displayed()
        print("✅ Главная страница загружена")

    def test_critical_api_health(self):
        """TC-SMOKE-03: Проверка здоровья основных API (можно запускать без UI)."""
        import requests
        critical_endpoints = ["/api/health", "/api/v1/products"]
        for endpoint in critical_endpoints:
            response = requests.get(f"https://api.baseurl{endpoint}")
            assert response.status_code == 200, f"Эндпоинт {endpoint} недоступен"
        print("✅ Критичные API отвечают")

3. Процесс постоянного ревью и обновления

Smoke-сценарии не статичны. Я регулярно (раз в спринт) пересматриваю набор по следующим правилам:

• Удаляю устаревшие проверки, потерявшие актуальность.
• Добавляю сценарии для нового критического функционала.
• Анализирую результаты прогонов. Если smoke-тест стабильно падает из-за нестабильности окружения, а не из-за реальных дефектов, я пересматриваю его целесообразность или изолирую проблему.
• Синхронизируюсь с разработкой: Обсуждаю с архитекторами и тимлидами изменения в системе, которые могут повлиять на «дымовой» контур.

4. Интеграция в CI/CD

Идеальный smoke-набор выполняется за 5-15 минут и является гейткипером в пайплайне. В .gitlab-ci.yml это может выглядеть так:

stages:
  - deploy_staging
  - smoke_test
  - deploy_production

smoke_testing:
  stage: smoke_test
  script:
    - echo "Запуск смоук-тестов на стенде staging..."
    - python -m pytest tests/smoke_suite.py -v --html=smoke_report.html
  artifacts:
    paths:
      - smoke_report.html
  only:
    - main
  allow_failure: false # Пайплайн не продолжится, если smoke упал

Итог: Мой подход — это баланс между скоростью, релевантностью и стабильностью. Smoke-тестирование должно быть надежным «сигналом тревоги» для команды, указывающим, что базовые функции сломаны и дальнейшее тестирование или выкатывание на прод бессмысленно, пока проблема не будет устранена. Выбор задач всегда основан на данных (история багов, кодовая база, бизнес-требования), а не на интуиции.