Смоук и санити-тесты: как быстро находить критические баги

Представьте ситуацию: разработчики прислали новый билд, вы с энтузиазмом начинаете глубокое регрессионное тестирование, тратите три часа на проверку сложных сценариев, и вдруг обнаруживаете, что главная кнопка «Купить» просто не нажимается. Весь потраченный день идет коту под хвост, потому что приложение в принципе не работает. Знакомо? Чтобы не попадать в такие ловушки, в тестировании qa is процессе обеспечения качества программного обеспечения, который включает в себя проверку функциональности, стабильности и соответствия требованиям используют два быстрых фильтра: смоук и санити-тесты.

Что такое смоук-тестирование и зачем оно нужно

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

Цель здесь не в том, чтобы найти все мелкие баги, а в том, чтобы понять: «Жив ли продукт вообще?». Если приложение не запускается или падает при попытке залогиниться, нет смысла тратить время на детальное тестирование. Билд просто возвращается разработчикам с вердиктом «Failed». Это экономит десятки часов работы всей команды.

Основные задачи смоук-тестов:

• Проверить, что система успешно запускается.
• Убедиться, что критические функции (например, авторизация, оплата, поиск) работают.
• Принять решение: готов ли билд к полноценному тестированию или он «мертв».

Санити-тестирование: проверка конкретных исправлений

Когда билд уже прошел смоук-тест и признан стабильным, в дело вступает Sanity testing (тестирование на здравый смысл). Если смоук проверяет всё приложение «по верхушкам», то санити - это узкий, но глубокий взгляд на конкретную область, где были внесены изменения.

Представьте, что в форме регистрации была ошибка: пользователи не могли ввести пароль с символом «@». Разработчик поправил код и вернул задачу в работу. Вам не нужно заново проверять всю систему оплаты или личный кабинет. Вы запускаете санити-тест именно для формы регистрации: пробуете разные комбинации паролей, проверяете граничные значения и смотрите, не сломалось ли что-то рядом.

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

Как не перепутать смоук-тесты с ретестом и регрессией

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

Во-первых, есть Re-testing (повторное тестирование). Это когда вы берете конкретный баг-репорт, повторяете шаги из него и проверяете, что ошибка исчезла. Это точечная проверка одного сценария. Санити-тест же шире: вы проверяете не только сам баг, но и то, как эта правка повлияла на соседние функции в том же модуле.

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

Практическое внедрение: как организовать процесс

Чтобы смоук и санити-тесты не превратились в хаос, их нужно структурировать в системе управления тестами (TMS). Самый простой и эффективный способ - использование тегов или специальных полей.

Вот как это обычно делают в командах:

1. Маркировка: Каждому тест-кейсу присваивается метка. Например, тег smoke для базовых проверок и sanity для функциональных модулей.
2. Создание чек-листа: Формируется отдельный набор (Suite) из 10-20 тестов, которые покрывают основные сценарии использования приложения (Critical Path).
3. Фильтрация: При поступлении билда тестировщик просто выбирает фильтр по тегу smoke и запускает только этот набор.
4. Автоматизация: Идеальный вариант - настроить запуск смоук-тестов автоматически в CI/CD пайплайне. Если автотесты «упали», билд даже не доходит до ручного тестировщика, а сразу возвращается разработчику.

   Когда именно запускать эти проверки?

   Чтобы не тратить время впустую, следуйте этим правилам:

   • После каждого нового билда $ ightarrow$ запуск смоук-тестов. Если приложение упало при старте, дальше не идем.
   • После исправления конкретного бага $ ightarrow$ ретест $ ightarrow$ санити-тест этого модуля. Убеждаемся, что фикс работает и не «отравил» соседние функции.
   • После обновления инфраструктуры или серверов $ ightarrow$ смоук-тесты. Проверяем, что связь с базой данных не пропала и API отвечает.
   • Сразу после релиза в продакшн (Smoke on Prod) $ ightarrow$ быстрый прогон базовых функций, чтобы убедиться, что деплой прошел успешно и пользователи не видят ошибку 500.

   Такой подход позволяет создать систему «раннего предупреждения». Вместо того чтобы искать иголку в стоге сена во время полной регрессии, вы отсекаете самые грубые ошибки на входе. Это не только ускоряет выпуск продукта, но и сохраняет нервы команде.

   Можно ли заменить смоук-тесты полноценной регрессией?

   Теоретически - да, но практически это катастрофа. Регрессия занимает много времени (от нескольких часов до нескольких дней). Если билд содержит критическую ошибку, вы узнаете об этом только в конце длинного цикла тестирования. Смоук-тесты позволяют узнать о проблеме за 15-30 минут.

   Что делать, если смоук-тест выявил некритическую ошибку?

   Если баг найден в смоук-тесте, но он не блокирует основной сценарий (например, опечатка в заголовке или сместившаяся кнопка), билд считается прошедшим. Ошибку заносят в баг-трекер, а тестирование продолжается. Если же функция «Купить» не работает - билд отклоняется сразу.

   Нужно ли автоматизировать санити-тесты?

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

   В чем главная разница между Smoke и Sanity?

   Смоук-тест проверяет «ширину» - всё ли в целом работает? Санити-тест проверяет «глубину» в конкретной точке - работает ли эта конкретная правка правильно и не сломала ли она что-то рядом?

   Может ли один и тот же тест быть и смоук, и санити?

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