Что такое smoke-тестирование и зачем его проводить

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

Все эти изменения нужно тестировать, чтобы приложение не упало, а новая функция не превратилась в баг. Для этого каждая сборка проходит несколько этапов проверки, прежде чем попасть к пользователям. Сегодня поговорим об одном из них — smoke-тестировании. Вы узнаете, что такое дымовые тесты, как их проводят, а также сможете сами попрактиковаться — просто повторяйте за нами.

Содержание

• Что означает smoke-тестирование и почему его так называют
• Место smoke-тестирования в цикле разработки
• Основные этапы дымового тестирования
• Практика: проводим smoke-тест страницы авторизации

Что означает smoke-тестирование и почему его так называют

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

Например, разработчики приложения маркетплейса добавили умную ленту отзывов с персонализированными рекомендациями. Прежде чем детально проверять новую функцию, тестировщик проводит smoke-тест и выясняет: запускается ли приложение без ошибок, могут ли пользователи войти в систему с корректными учётными данными, добавить товар в корзину и завершить оплату. Если хотя бы одна из базовых функций сломана, дальнейшее тестирование не имеет смысла — сборку отправляют на доработку с подробным баг-репортом.

Smoke в переводе с английского означает «дым» — отсюда и название «дымовое тестирование». Существует две основные версии происхождения этого термина. Первая отсылает к работе печных мастеров: после постройки печи её затапливали и наблюдали за движением дыма. Если дым выходил только через дымоход, а не через щели в кладке, печь считалась исправной и проходила проверку.

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

Вам могут встретиться и другие термины: build acceptance testing (тестирование приёмки сборки) — проверка стабильности сборки перед началом тестирования; или intake testing (входное тестирование) — первичная проверка перед допуском к дальнейшему тестированию. Например, в одной компании принято говорить «запускаем smoke-тесты после каждого билда», а в другой — «проводим build acceptance testing новой сборки». Суть везде одинаковая: от вас нужна быстрая проверка критичных функций перед передачей на дальнейшее тестирование.

Читайте также:

Баг-репорт: что это и как его правильно составить

Место smoke-тестирования в цикле разработки

Smoke-тестирование относится к группе проверок, связанных с изменениями (change-related testing). Эта группа состоит из следующих четырёх тестов:

• Smoke-тестирование — первая и самая быстрая проверка приложения.
• Re-testing (повторное тестирование) — это точечная проверка конкретного исправленного дефекта. Тестировщик повторяет точные шаги из баг-репорта и убеждается, что проблема больше не воспроизводится.
• Sanity-тестирование — узкая, но глубокая проверка конкретной области после небольших изменений. Например, если разработчики исправили форму регистрации, sanity-тест проверяет только её: разные сценарии ввода пароля, граничные случаи и взаимодействие со связанными компонентами.
• Regression-тестирование — полная проверка всего приложения. Она помогает убедиться, что новые изменения не сломали существующий функционал. Это самый долгий и глубокий вид тестирования в группе.

Представьте, что вы покупаете подержанный автомобиль. В этом случае дымовой тест можно сравнить с первичным осмотром, где вы проверяете самое основное: заводится ли двигатель, включаются ли фары, открываются ли двери, крутится ли руль, работают ли тормоза. Если хотя бы что-то одно из этого не работает — дальше осматривать автомобиль нет смысла, его нужно сначала отремонтировать.

Допустим, продавец упоминает: «На прошлой неделе заменил аккумулятор». Это повод для повторного тестирования (re-testing) — вы проверяете то, что было исправлено: держит ли аккумулятор заряд, нет ли проблем с электропитанием.

Затем продавец сообщает, что недавно также заменил всю тормозную систему, — и вы проверяете тормоза во всех режимах: на разных скоростях, при резком торможении, на наличие посторонних звуков, на равномерность торможения всех колёс. Это напоминает sanity-тест — глубокую проверку изменённой области.

Наконец, перед покупкой вы едете на СТО для полной диагностики. Там специалисты проверяют двигатель, подвеску, трансмиссию, электрику, тормозную систему, кузов на коррозию — буквально весь автомобиль по заготовленному чек-листу. Это regression-тест — комплексная проверка системы.

Основные этапы дымового тестирования

Дымовое тестирование состоит из четырёх этапов: планирования, подготовки тестовой среды, запуска тестов и анализа результатов. Иногда планирование и подготовку среды объединяют в один этап. Мы будем придерживаться первого варианта и разберём все этапы на примере тестирования страницы авторизации.

Представьте, что текущая версия (билд 1.0) страницы авторизации интернет-магазина позволяет двум типам пользователей — покупателям и администраторам — входить в систему через логин и пароль. Новый билд 2.0 добавляет ещё один способ входа — аутентификацию по одноразовому коду, который система будет отправлять на электронную почту. Давайте рассмотрим, как в таком случае будет организовано smoke-тестирование для этого обновления.

Планирование

Сначала команда определяет объём тестирования — выбирает минимальный набор проверок основной функциональности и новых возможностей приложения. В этом помогают простые логические вопросы: какие функции критичны для работы системы? Какие области затронуты текущими изменениями? Какие компоненты должны работать в первую очередь для продолжения более глубокого тестирования? Что произойдёт, если эта функция сломается в продакшене?

После планирования у команды появляется набор высокоуровневых тест-кейсов или чек-лист с шагами проверки. Список должен быть достаточно кратким для быстрого выполнения — обычно дымовое тестирование занимает 15–60 минут.

Для страницы авторизации план включает следующие проверки:

• Запуск: страница авторизации загружается.
• Существующая функция: вход пользователя с корректными данными.
• Существующая функция: вход администратора с корректными данными.
• Новая функция: запрос одноразового кода.
• Новая функция: вход с использованием корректного одноразового кода.
• Негативный сценарий: вход с некорректными данными ведёт к ошибке.

Подготовка среды

После подготовки плана настраивают тестовое окружение. Дымовые тесты никогда не проводятся в продакшене, где работают реальные пользователи. Для этого создают отдельную изолированную среду — тестовый стенд. Такая среда должна быть стабильной и максимально близкой к реальной по конфигурации: с той же версией операционной системы, базы данных и других компонентов.

В тестовой среде разворачивают новую сборку приложения — ту самую, которую предстоит проверить. Команда готовит необходимые тестовые данные: создаёт учётные записи пользователей с известными логинами и паролями, настраивает заглушки внешних сервисов, проверяет доступность всех нужных зависимостей.

Для нашего примера это означает, что в базе данных тестового стенда должны быть созданы учётные записи с логинами user и admin с соответствующими паролями (pass и adminpass). Также все зависимые микросервисы должны быть доступны и корректно отвечать на запросы. А вместо реального сервиса отправки email-кодов используется заглушка (mock): она не отправляет настоящие письма на почту, а просто фиксирует запросы на отправку и возвращает подтверждение их получения, позволяя узнать сгенерированный код.

Тут оговоримся: далее в практической части статьи мы намеренно упростим схему. Вместо сложной архитектуры с реальными сервисами мы эмулируем всю логику в JavaScript-коде страницы. Это позволит нам сосредоточиться на самом процессе smoke-тестирования, а не на технических деталях инфраструктуры.

Запуск тестов

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

Ручное выполнение тестов имеет смысл на ранних стадиях проекта или при единичных проверках. Далее, по мере роста приложения, smoke-тесты почти всегда автоматизируют и запускают после каждой сборки — например, через систему CI/CD. Это позволяет получать оперативную обратную связь о стабильности билда, часто — в течение нескольких минут после его создания.

В этой статье у нас небольшой учебный проект, поэтому мы вручную откроем новый HTML-файл в браузере. Затем поочерёдно проверим все пункты плана: попробуем войти как user, затем как admin, после чего протестируем новую функцию с одноразовым кодом. Каждый шаг и результат будем фиксировать.

Анализ результатов

После выполнения всех тестов команда получает один из двух вариантов:

• «Да» — сборка прошла тест. Все критические функции работают, новая сборка стабильна. Её можно передавать на следующий этап тестирования.
• «Нет» — сборка провалила тест, найден критический дефект.

Теперь, когда мы разобрали все четыре этапа в теории, пора применить эти знания на практике и самим попробовать провести дымовое тестирование.

Читайте также:

Что такое QA-тестирование и как оно устроено

Практика: проводим smoke-тест страницы авторизации

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

Чтобы попрактиковаться, скачайте архив smoke-test-project с двумя билдами страницы авторизации. Первый билд — это базовая версия с авторизацией по логину и паролю. Второй билд — версия с аутентификацией по одноразовому коду, который отправляется на email. Именно второй билд мы будем тестировать.

Мы добавили в него ошибку, чтобы вы увидели, как smoke-тест её находит. Представьте, что разработчик закомментировал код входа для администраторов, пока добавлял новую функцию. В результате админы не могут войти в систему со своими учётными данными, хотя обычные пользователи входят без проблем.

Составляем план и готовим тестовую среду

Составим чек-лист дымового тестирования для нового билда:

• SMOKE-01: Загрузка страницы. Ожидаемый результат: страница (билд 2.0) загружается, обе формы видны.
• SMOKE-02: Старая функция User. Вводим user/pass. Ожидаемый результат: сообщение «Вход успешен!».
• SMOKE-03: Старая функция Admin. Вводим admin/adminpass. Ожидаемый результат: сообщение «Вход успешен (Admin)!».
• SMOKE-04: Новая функция OTP — получаем код. Вводим test@example.com и нажимаем «Получить код». Ожидаемый результат: появляется диалоговое окно — alert () — с кодом «123456», отображается поле для ввода кода.
• SMOKE-05: Новая функция OTP — вход. Вводим «123456» и жмём «Войти с кодом». Ожидаемый результат: сообщение «Вход по коду успешен!».
• SMOKE-06: Негативная проверка. Вводим user/wrong. Ожидаемый результат: сообщение «Неверный логин или пароль».

Теперь подготовим тестовую среду. Откройте любой редактор кода и распакуйте туда скачанный архив smoke-test-project. Внутри вы найдёте два файла: build-current.html (текущая версия) и build-new.html (новый билд с OTP). Это и будет наша тестовая среда. Далее откройте файл build-new.html в браузере, держите составленный чек-лист под рукой и приготовьтесь искать баг.

Пишем и проводим тесты

Открываем файл build-new.html в браузере и начинаем работать с чек-листом.

Если страница открылась и обе формы видны — мы прошли первый тест SMOKE-01. Затем вводим user в поле «Логин» и pass в поле «Пароль». Нажимаем кнопку Войти. На экране появляется зелёное сообщение «Вход успешен!» — это полностью совпадает с ожидаемым результатом теста SMOKE-02, значит авторизация обычного пользователя работает корректно. Продолжаем проверку.

Переходим к тесту SMOKE-03 — ключевой проверке. Вводим admin/adminpass и нажимаем Войти. Появляется красное сообщение «Неверный логин или пароль», однако мы ожидали «Вход успешен (Admin)!». Результаты не совпадают.

Переходим к следующей проверке. Вводим test@example.com в поле Email и нажимаем «Получить код». Появляется alert с текстом «Код отправлен на test@example.com. Ваш код: 123456». Поле для ввода кода в форме становится видимым. Результат совпадает с ожидаемым — тест SMOKE-04 пройден.

На очереди проверка SMOKE-05. Вводим «123456» в поле «Код» и нажимаем «Войти с кодом». Появляется приятное для тестировщика зелёное сообщение «Вход по коду успешен!». Это совпадает с ожидаемым результатом — тест пройден.

Наконец, проводим последний тест SMOKE-06 (негативная проверка): вводим user/wrong — неправильные учётные данные. Получаем ожидаемое сообщение «Неверный логин или пароль». Тест пройден, и можем подводить итоги.

Мы провели тестирование и нашли критический дефект. Новая функция работает, но разработчик сломал старую — вход для админа. Составим итоговую таблицу.

Составляем отчёт

Создайте в папке smoke-test-project файл с названием smoke_report.md. Скопируйте отчёт с результатами нашего тестового прогона и вставьте в этот файл:

=== Отчёт о дымовом тестировании ===

Дата: [вставьте текущую дату и время]
Сборка: Билд 2.0 (OTP Feature)

Итоговый статус сборки: Failed

--------------------------------------
Детали прогона:
--------------------------------------

[Passed] SMOKE-01: Загрузка страницы
 > Описание: Страница загружается, обе формы видны
 > Комментарий: OK

[Passed] SMOKE-02: Старая функция (User)
 > Ввод: "user" / "pass"
 > Ожидалось: "Вход успешен!"
 > Получено: "Вход успешен!"
 > Комментарий: OK

[Failed] SMOKE-03: Старая функция (Admin)
 > Ввод: "admin" / "adminpass"
 > Ожидалось: "Вход успешен (Admin)!"
 > Получено: "Неверный логин или пароль."
 > Комментарий: Блокирующий дефект. Регрессия.

[Passed] SMOKE-04: Новая функция (OTP -- получение кода)
 > Запрос кода по email
 > Ожидалось: Alert с кодом '123456'
 > Получено: Alert с кодом '123456'
 > Комментарий: Новая фича работает (часть 1)

[Passed] SMOKE-05: Новая функция (OTP -- вход)
 > Ввод корректного кода '123456'
 > Ожидалось: "Вход по коду успешен!"
 > Получено: "Вход по коду успешен!"
 > Комментарий: Новая фича работает (часть 2)

[Passed] SMOKE-06: Негативная проверка
 > Ввод: "user" / "wrong"
 > Ожидалось: "Неверный логин или пароль."
 > Получено: "Неверный логин или пароль."
 > Комментарий: OK

--------------------------------------
Решение:
Сборка отклонена. Дальнейшее тестирование невозможно 
до исправления дефекта SMOKE-03.

Мы получили артефакт — отчёт о дымовом тестировании. Он чётко показывает, что новая сборка провалила тест из-за блокирующего дефекта в функции авторизации администратора (тест SMOKE-03). Немедленно отправляем отчёт разработчикам с указанием конкретной проблемы и отклоняем билд. Дальнейшее тестирование бесполезно, пока разработчики не исправят вход для админа. Поздравьте себя — вы провели первый тест и сэкономили команде кучу времени.

Что дальше

Мы попрактиковались в ручном тестировании, но сегодня большинство тестов автоматизируют. Один из ключевых инструментов для этого — Selenium. Это фреймворк с открытым исходным кодом, который позволяет написать код, управляющий браузером. Он открывает страницы, кликает по элементам, заполняет формы и проверяет содержимое — всё то, что мы делали вручную, но автоматически и за доли секунды. Мастхэв для современного тестировщика.

Также рекомендуем добавить в закладки глоссарий ISTQB — здесь вы найдёте все термины, которые используются в тестировании программного обеспечения. ISTQB (International Software Testing Qualifications Board) — это международная организация, которая разрабатывает единые стандарты и программы сертификации для тестировщиков по всему миру. Сертификаты ISTQB широко признаны и ценятся многими работодателями в IT-индустрии.

Ещё советуем книгу «Искусство тестирования программ» Гленфорда Майерса, Тома Баджетта и Кори Сандлера. Эта широко известная книга впервые вышла в 1979 году, но остаётся актуальной и сегодня. Она учит фундаментальным принципам тестирования: как выявлять скрытые дефекты, проектировать эффективные тест-кейсы и думать как опытный тестировщик, а не просто механически проверять функциональность приложения.