Можно ли выпускать софт в релиз с багом на Smoke?

Можно ли выпускать релиз с багом на Smoke-тестах?

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

Однако, как опытный инженер, я должен рассмотреть вопрос глубже, так как в реальной практике иногда возникают исключительные обстоятельства. Решение всегда должно быть осознанным, документированным и коллективным, а не попыткой скрыть проблему.

Почему Smoke-тесты — это "красная линия"

Smoke-Testing — это проверка жизнеспособности сборки. Его падение означает, что:

• Не работает "ядро" продукта: Сломан базовый сценарий (например, пользователь не может авторизоваться, главная страница не загружается, ключевая транзакция не выполняется).
• Сборка или деплой выполнены некорректно: Возникли проблемы с зависимостями, конфигурацией, миграциями базы данных.
• Внесена регрессия в общий код: Изменение в одном модуле сломало фундаментальную функциональность другого.

Выпуск в таком состоянии почти гарантированно приведёт к:

1. Падению продакшн- среды и простою, что напрямую ударит по репутации и финансам.
2. Невозможности использовать продукт основной массой пользователей.
3. Эскалации инцидента (Sev-1/Sev-2) и экстренному горячему фиксу, который будет делаться в условиях стресса и может внести новые ошибки.

Исключительные обстоятельства и процесс принятия решения

В редких случаях вопрос о релизе с падающим Smoke может быть рассмотрен, но только при соблюдении строгого процесса. Решение НИКОГДА не принимается QA или разработчиком в одиночку. Это риск-менеджмент на уровне всего проекта.

Возможные сценарии для обсуждения:

• Баг в самом Smoke. тесте: Скрипт устарел, проверяет убранную функциональность, содержит ошибку логики или зависит от неустойчивого тестового окружения.

    *   **Действие:** Немедленно исследовать и починить Smoke-

тест. Если баг теста подтверждён, тест можно отключить на время, выпустить релиз и немедленно восстановить валидный Smoke. тест после.

• Баг не затрагивает основную ветку функциональности (false positive Smoke): Например, Smoke включает проверку "неосновного" виджета на главной странице, которая падает, в то время как все ключевые пользовательские пути (логин, поиск, покупка) работают.

    *   **Действие:** Пересмотреть состав Smoke.

тестов. Настоящий Smoke должен быть сверхминималистичным. Возможно, этот тест стоит переместить в регрессионную suite. Решение о релизе принимается после анализа реального риска.

• Критический хотфикс, который закрывает баг с более высоким приоритетом, чем падающий Smoke.

    *   **Действие:** Чрезвычайно редкая ситуация. Необходимо провести совещание (риск-митинг) с участием **руководителя продукта, тимлида разработки, ведущего QA и ответственного за эксплуатацию (Ops/DevOps)**. Обсудить:
        *   Что именно ломает Smoke?
        *   Какой процент пользователей затронут?
        *   Можно ли выпустить фикс с feature-

toggle или другим механизмом обхода?

        *   Каков план по немедленному исправлению Smoke-

бага после релиза?

    *   Решение и его rationale **обязательно документируются**.

Практический пример процесса на основе кода

Представьте, что Smoke- тест проверяет доступность API- ендпоинта /api/health. Его падение — абсолютный стоп- сигнал.

# smoke_test_api.py
import requests

def test_api_health():
    """SMOKE-
TEST: Проверка жизнеспособности основного API."""
    response = requests.get('https://prod.example.com/api/health', timeout=10)
    assert response.status_code == 200, "API HEALTH ENDPOINT IS DOWN!"
    assert response.json()['status'] == 'OK', "API status is not OK!"

Если этот тест падает, вы просто не можете развернуть новую версию. Но что если падает другой тест, который, возможно, слишком "тяжёлый" для Smoke?

# Возможно, это НЕ совсем Smoke-
тест
def test_promo_banner_presence():
    """Проверка, что рекламный баннер отображается на главной."""
    # ... сложный Selenium-
скрипт ...
    assert banner.is_displayed(), "Promo banner is missing!" # Падение здесь

В этом случае команда должна оценить: "Можем ли мы выпустить релиз, если у 100% пользователей работает корзина покупок, но у 0% не показывается рекламный баннер?" Ответ, скорее всего, "да", но после этого тест test_promo_banner_presence должен быть вынесен из Smoke- suite.

Резюме и лучшие практики

1. Smoke- тесты должны быть безупречными и атомарными. Их набор должен пересматриваться и быть минимальным.
2. Падение Smoke — это "красный" статус сборки. Сборка не готова к ручному, а тем более автоматическому развёртыванию.
3. Решение об игнорировании падающего Smoke — это управление рисками, а не тестирование. Оно требует эскалации, коллективного решения и документации.
4. Автоматизация. Smoke- тесты должны быть частью CI/CD- пайплайна и блокировать продвижение сборки на прод (например, в Jenkins, GitLab CI).

# Пример stage в GitLab CI
stages:
  - build
  - smoke_test  # Эта стадия должна пройти, чтобы запустилась deploy
  - deploy

smoke_test:
  stage: smoke_test
  script:
    - pytest smoke_suite/ -v
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # Запускать только для main/master

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