Когда применяется Smoke?

Применение Smoke-тестирования в процессе разработки ПО

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

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

• После каждой новой сборки (Build). Это основной и самый частый сценарий. Команда QA получает свежий билд от разработчиков. Запускается smoke-набор, чтобы проверить, не сломал ли новый код базовую работу приложения.
• После развертывания на новом окружении. Например, при переносе приложения с тестового стенда на стейджинг или продакшн. Smoke-тесты подтверждают, что развертывание прошло успешно и ключевые функции доступны.
• Перед запуском полного цикла регрессионного тестирования. Регресс — это долгий и ресурсоемкий процесс. Нет смысла запускать сотни тестов, если билд не проходит даже базовые проверки. Smoke служит "воротами" для глубокого тестирования.
• После "горячих" фиксов (Hotfix) в продакшн-окружении. Когда в продуктивной среде обнаруживается критический баг и его срочно чинят, smoke-набор помогает быстро проверить, что сам фикс работает и не нарушил сопутствующие модули.
• При интеграции с другими системами или масштабном обновлении. Например, после обновления версии базы данных, веб-сервера или интеграции с новым платежным шлюзом.

Суть и содержание Smoke-тестов

Smoke-набор должен быть:

• Быстрым (от нескольких минут до часа).
• Стабильным (выполняться автоматически без ручных вмешательств).
• Сфокусированным на "ядре" продукта.
• Детерминированным (давать четкий результат: проход/непроход).

Пример набора для условного интернет-магазина:

1. Запуск главной страницы.
2. Авторизация существующим пользователем.
3. Поиск товара по каталогу.
4. Добавление товара в корзину.
5. Начало процесса оформления заказа (до момента оплаты).

Если какой-то из этих шагов падает, дальнейшее тестирование приостанавливается, сборка бракуется и возвращается разработчикам на доработку.

Техническая реализация

На практике smoke-тесты почти всегда автоматизированы. Они могут быть реализованы как часть Continuous Integration (CI) пайплайна. В коде это выглядит как отдельный набор, помеченный специальным тегом (например, @smoke).

Пример на Python с использованием pytest:

import pytest

class TestSmokeStore:

    @pytest.mark.smoke
    def test_main_page_loads(self, web_driver):
        """Проверка загрузки главной страницы."""
        web_driver.get("https://example-shop.com")
        assert "Example Shop" in web_driver.title
        assert web_driver.find_element("id", "main-logo").is_displayed()

    @pytest.mark.smoke
    def test_user_login(self, auth_fixture, web_driver):
        """Проверка авторизации."""
        web_driver.get("https://example-shop.com/login")
        auth_fixture.login("valid_user@mail.com", "valid_pass")
        assert web_driver.find_element("id", "user-welcome").text == "Welcome, User!"

    @pytest.mark.smoke
    def test_search_functionality(self, web_driver):
        """Проверка поиска товара."""
        search_input = web_driver.find_element("id", "search-field")
        search_input.send_keys("laptop")
        search_input.submit()
        results = web_driver.find_elements("class", "product-item")
        assert len(results) > 0

Запуск такого набора из командной строки будет целенаправленным:

pytest -v -m smoke

Ценность для команды и процесса

• Экономия времени и ресурсов. Раннее отсечение нестабильных сборок предотвращает бесполезную трату сил тестировщиков.
• Быстрая обратная связь разработчикам. Они почти мгновенно узнают, если их изменения сломали билд.
• Повышение уверенности в качестве артефакта. Успешный проход smoke-тестов дает "зеленый свет" для следующих этапов тестирования.
• База для санитарного тестирования (Sanity Testing). Часто эти понятия пересекаются, но в классическом понимании smoke проверяет стабильность сборки, а sanity — корректность конкретной функциональности после изменений.

Заключение

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