Ответ
Это виды тестирования, отличающиеся по цели, глубине и объему проверок, выполняемых на разных этапах разработки.
Smoke-тестирование (Дымовое, Build Verification Test - BVT)
- Цель: Быстро проверить, что критически важные функции системы работают после новой сборки (билда) или развертывания. Ответ на вопрос: "Можно ли начинать более глубокое тестирование?"
- Объем: Минимальный набор позитивных сценариев, покрывающих основной путь (happy path) ключевых модулей (например, запуск приложения, аутентификация, создание сущности).
- Когда выполняется: Сразу после каждой новой сборки. Часто автоматизировано и запускается в CI/CD первым.
- Мой опыт: В одном из проектов smoke-сценарий состоял из 15 автоматизированных тестов, которые проверяли доступность главной страницы, логин, переход в личный кабинет и отображение основных виджетов. Если падал хотя бы один — сборка считалась непригодной для регресса.
Sanity-тестирование (Санитарное, "здравомыслие")
- Цель: Узконаправленная проверка конкретных изменений (нового функционала или исправления бага) после smoke-тестов. Ответ на вопрос: "Работает ли именно то, что мы изменили, как ожидалось?"
- Объем: Неглубокое тестирование только затронутой функциональности и смежных областей.
- Когда выполняется: После smoke-тестов, перед полным регрессом. Часто выполняется вручную.
- Пример: После исправления бага с расчетом скидки в корзине, sanity-чек включает: добавление товара, применение скидки, оформление заказа. Мы не проверяем весь функционал корзины, а только сценарии, связанные с исправлением.
Regression-тестирование (Регрессионное)
- Цель: Полная проверка всего существующего функционала приложения после изменений. Ответ на вопрос: "Не сломали ли новые изменения что-то работавшее ранее?"
- Объем: Максимально широкий. Включает повторное выполнение всех релевантных тестов (функциональных, интеграционных, иногда нефункциональных) для проверки ранее работавшей функциональности.
- Когда выполняется: После sanity-тестирования, перед выпуском версии в продакшн. Активно автоматизируется.
- Мой подход: Регрессионный набор у нас делился на "полный" (запускался перед релизом) и "быстрый" (ядро критических тестов, запускался ежедневно). Мы использовали теговую систему в Pytest (
@pytest.mark.regression,@pytest.mark.smoke) для гибкого управления запуском.
Итог: Smoke — "заводится ли машина?", Sanity — "работает ли новая печка?", Regression — "а все остальное в машине после установки печки работает как раньше?"