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

Sanity Testing vs Smoke Testing: полное разъяснение

Введение

Эти два термина часто путают, даже опытные QA специалисты. Хотя они похожи по цели (быстрая проверка), они имеют разные фокусы, разные сценарии применения и разные уровни детализации. За 10+ лет я видел много ошибок в их интерпретации, поэтому давайте разберёмся.

Определения

Smoke Testing

Smoke Testing — быстрая, поверхностная проверка после сборки, которая убеждает, что приложение вообще запускается и основной функционал работает. Это гейткипер перед полным тестированием.

Цель: ответить на вопрос "Можно ли переходить к более глубокому тестированию?"

Sanity Testing

Sanity Testing — проверка логики специфичного функционала или части системы после небольших изменений. Это убеждает, что изменения не сломали то, что должно было быть изменено.

Цель: ответить на вопрос "Делает ли это именно то, что требовалось?"

Детальное сравнение

1. Когда применяются

Smoke:

• Сразу после сборки (build stage)
• Перед тем как отправить в dev/staging
• На CI/CD pipeline как первый gate
• После каждого мержа в shared branch
• Несколько раз в день

Sanity:

• После небольшого изменения кода (hotfix, bug fix)
• Когда разработчик говорит "исправил баг в функции X"
• Перед тем как отправлять на регрессионное тестирование
• На конкретном куске функционала
• Один раз после изменения

2. Объём и охват

Smoke:

• Проверяет целое приложение в целом
• Все критические пути
• Например: логин → главная страница → навигация между основными разделами
• 5-10% от всех тестов
• Охватывает всё приложение

Sanity:

• Проверяет конкретный функционал или компонент
• Только то, что было изменено + прилежащие области
• Например: если исправили форму логина, проверяем логин + восстановление пароля
• 1-3% от всех тестов
• Локальный охват

3. Время выполнения

Smoke:

• 15-30 минут
• Запускается часто
• Блокирует разработку если упал

Sanity:

• 5-15 минут (обычно короче чем smoke)
• Запускается редко, по ситуации
• Не блокирует разработку (это локальная проверка)

4. Уровень детализации

Smoke:

• Высокоуровневая проверка
• Happy path только
• Нет edge cases
• Нет граничных значений
• Нет performance checks

Sanity:

• Более детальная проверка конкретного функционала
• Happy path + основные sad paths
• Может включать некоторые edge cases
• Может включать базовую валидацию
• Фокус на том, что изменилось

5. Кто запускает

Smoke:

• CI/CD pipeline (автоматически)
• QA team (или developers в DevOps культуре)
• Всегда автоматизирован

Sanity:

• QA инженер (вручную или автоматизирован)
• Может быть developer перед тем как делать pull request
• Может быть ручное или автоматизированное

6. Реакция на падение

Smoke (упал):

• Критичная проблема
• Сборка отправляется обратно
• Разработчик срочно исправляет
• Никому нельзя ничего мерджить в main

Sanity (упал):

• Локальная проблема
• Разработчик переделывает работу
• Не отправляется на регрессию
• Не отправляется в production

Практические примеры

Сценарий 1: Разработчик исправил баг в логине

Sanity проверка:

1. Логин с корректными данными — работает
2. Логин с неправильным паролем — ошибка 401
3. Логин с пустым email — валидация ошибки
4. После логина редирект на главную — работает
5. Логаут — работает
Время: 10 минут
Результат: готово к регрессии

Smoke проверка (на вся сборка):

1. Приложение запускается
2. Логин работает
3. Главная страница доступна
4. Навигация работает
5. API ответ получается
6. БД соединение живо
7. Основные компоненты загружаются
Время: 20 минут
Результат: сборка пригодна для дальнейшего тестирования

Сценарий 2: Новая функция "темный режим"

Sanity для темного режима:

1. Клик на кнопку "темный режим" — включается
2. Клик ещё раз — выключается
3. Цвета меняются правильно
4. Текст читаем
5. При перезагрузке состояние сохраняется
Время: 5 минут
Результат: готово к регрессии и production

Smoke для всего приложения: Проверяет, что все остальное ещё работает с новым кодом темного режима.

Таблица сравнения

Частые ошибки

Ошибка 1: Путают в названии

"Сделаем sanity smoke тесты" — это неправильно. Это два разных типа.

Ошибка 2: Sanity как замена для Smoke

Кто-то думает, что можно вместо smoke запустить sanity. Неправильно — sanity не охватывает всё приложение.

Ошибка 3: Smoke слишком детальный

Если smoke тесты занимают 2 часа — это не smoke. Это регрессия.

Ошибка 4: Sanity слишком поверхностный

Если sanity только проверяет, что компонент открывается — это неправильно. Нужна логика.

Моя рекомендация для процесса

Разработчик пушит код
        ↓
CI/CD: Smoke тесты (15 мин) ← гейткипер
        ↓
Прошли? ← нет → обратно разработчику
Да ↓
QA: Sanity тесты (10 мин) ← локальная проверка
        ↓
Прошли? ← нет → обратно разработчику
Да ↓
QA: Регрессионные тесты (4 часа)
        ↓
Production deployment

Заключение

Smoke = общая проверка всего (гейткипер) Sanity = локальная проверка изменения (контроль качества)

Оба необходимы, но для разных целей. Smoke запускается часто и автоматически, sanity запускается по необходимости на конкретном изменении.

У нас в компании есть автоматические smoke тесты в CI/CD, но sanity часто делается вручную, так как это требует понимания именно того, что изменилось.