Smoke vs Sanity vs Regression Testing: В Чем Разница?

В тестировании программного обеспечения три термина часто путают: Smoke Testing (Дымовое Тестирование), Sanity Testing (Проверка на Вменяемость) и Regression Testing (как обсуждается в Black Box Testing: Techniques and Approaches) (Регрессионное Тестирование). Хотя они могут казаться похожими, каждый служит отдельной цели в жизненном цикле разработки ПО. Понимание того, когда и как использовать каждый тип, критически важно для эффективного тестирования.

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

Быстрое Сравнение

Smoke Testing: “Можем Ли Мы Вообще Начать Тестирование?”

Что Такое Smoke Testing?

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

Термин происходит от тестирования оборудования: если вы включаете устройство и оно начинает дымиться, что-то серьезно не так.

Ключевые Характеристики

• Быстро: Максимум 15-30 минут
• Поверхностно: Тестирует только критическую функциональность высокого уровня
• Решение Go/No-Go: Пройден = продолжить тестирование, Провален = отклонить сборку
• Широкое Покрытие: Касается многих функций, но не углубляется
• Точка Входа: Первое тестирование, проведенное на новой сборке

Что Покрывает Smoke Testing

• ✅ Приложение запускается успешно

• ✅ Функциональность входа работает

• ✅ Критические страницы/экраны загружаются

• ✅ Навигация между основными модулями работает

• ✅ Нет критических падений или блокеров

• ❌ Детальная функциональность

• ❌ Граничные случаи

• ❌ Валидация данных

• ❌ Сложные рабочие процессы

Пример Smoke Testing

Smoke Test E-commerce Приложения (20 минут)

1. Запуск Приложения
   ✓ Приложение загружается без ошибок
   ✓ Домашняя страница отображается корректно

2. Аутентификация Пользователя
   ✓ Страница входа доступна
   ✓ Можно войти с валидными данными
   ✓ Выход работает

3. Основные Функции (Только Счастливый Путь)
   ✓ Строка поиска принимает ввод
   ✓ Страница продукта загружается
   ✓ Добавить в корзину работает
   ✓ Страница просмотра корзины отображается
   ✓ Страница оформления заказа доступна

4. Критические API
   ✓ Сервис пользователя отвечает (200 OK)
   ✓ Сервис продукта отвечает (200 OK)
   ✓ Платежный шлюз отвечает (200 OK)

Решение: Если ЛЮБОЙ из них не пройден → Отклонить сборку, вернуть разработчикам

Шаблон Чеклиста Smoke Test

# Smoke Test - Build #v2.5.3
Дата: 2025-10-02 | Тестер: QA Lead

## Окружение
- URL: https://staging.app.com
- Браузер: Chrome 120

## Результаты

| Модуль | Тест | Статус | Заметки |
|--------|------|--------|---------|
| Запуск | App загружается | ✅ Пройден | |
| Auth | Login работает | ✅ Пройден | |
| Auth | Logout работает | ✅ Пройден | |
| Продукты | Поиск работает | ✅ Пройден | |
| Продукты | Страница продукта загружается | ✅ Пройден | |
| Корзина | Добавить в корзину | ✅ Пройден | |
| Checkout | Страница checkout загружается | ✅ Пройден | |

**Решение**: ✅ СБОРКА ПРИНЯТА - Продолжить полное тестирование

---

Если любой критический тест не пройден:
**Решение**: ❌ СБОРКА ОТКЛОНЕНА - Вернуть в разработку

Когда Использовать Smoke Testing

• ✅ После каждого развертывания новой сборки
• ✅ Перед началом полного цикла тестирования
• ✅ После слияния основных веток функций
• ✅ В CI/CD пайплайнах (автоматизированные smoke-тесты)
• ✅ При решении, можно ли тестировать сборку

Sanity Testing: “Исправили Ли Мы То, Что Заявили?”

Что Такое Sanity Testing?

Sanity Testing (также называемое Narrow Regression Testing) (как обсуждается в Risk-Based Testing: Prioritizing Test Efforts for Maximum Impact) — это быстрый, сфокусированный тест для проверки того, что конкретное исправление бага или небольшое изменение работает, как ожидается. Это как проверка того, что ремонт, который вы сделали на автомобиле, действительно исправил проблему.

Ключевые Характеристики

• Узкая Область: Тестирует только измененную область
• Без Скрипта: Обычно не документируется формально
• Быстро: 30-60 минут
• Глубоко в Измененной Области: Идет глубже, чем smoke testing
• Проверка После Исправления: Выполняется после исправления багов или небольших изменений

Что Покрывает Sanity Testing

• ✅ Конкретный баг, который был исправлен

• ✅ Функциональность, связанная с исправлением

• ✅ Непосредственные зависимости

• ❌ Все приложение

• ❌ Несвязанные функции

• ❌ Полная регрессия

Пример Sanity Testing

Сценарий: Исправление Бага - “Email сброса пароля не отправляется”

Отчет о Баге:

ID Бага: BUG-1234
Проблема: Пользователи не получают emails сброса пароля
Исправление: Обновлена конфигурация сервиса email
Сборка: v2.5.4

Sanity Test (45 минут):

Область Фокуса: Поток Сброса Пароля

1. Запустить Сброс Пароля
   ✓ Нажать ссылку "Забыли Пароль?"
   ✓ Ввести валидный email адрес
   ✓ Отправить форму
   ✓ Проверить, что сообщение об успехе отображается

2. Проверить Отправку Email
   ✓ Проверить почтовый ящик email (тестовый аккаунт)
   ✓ Email получен в течение 2 минут
   ✓ Email содержит ссылку сброса
   ✓ Форматирование email корректно

3. Завершить Сброс Пароля
   ✓ Нажать ссылку сброса в email
   ✓ Ссылка открывает страницу сброса
   ✓ Ввести новый пароль
   ✓ Подтвердить сброс пароля
   ✓ Проверить сообщение об успехе

4. Проверить, что Новый Пароль Работает
   ✓ Войти с новым паролем
   ✓ Вход успешен
   ✓ Старый пароль отклонен

5. Связанная Функциональность (Sanity Check)
   ✓ Обычный вход все еще работает
   ✓ Email уведомления для других действий работают
   ✓ Профиль пользователя отображает email правильно

Решение: Если исправление работает → Принять изменение, продолжить тестирование
         Если исправление не работает → Отклонить, отправить обратно для переделки

Когда Использовать Sanity Testing

• ✅ После исправления бага для проверки его решения
• ✅ После небольших изменений кода
• ✅ После небольших обновлений конфигурации
• ✅ Перед запуском полной регрессии
• ✅ Когда время ограничено (быстрая валидация)

Sanity vs Smoke: Ключевое Различие

Smoke Testing:
"Работает ли приложение вообще?"
Область: Все приложение (поверхностно)
Пример: Могу ли я войти, искать, добавить в корзину?

Sanity Testing:
"Работает ли это конкретное исправление/изменение?"
Область: Одна функция/область (глубоко)
Пример: Отправляется ли теперь email сброса пароля?

Regression Testing: “Сломали Ли Мы Что-то Еще?”

Что Такое Regression Testing (как обсуждается в Shift-Left Testing: Early Quality Integration for Cost Savings)?

Regression Testing проверяет, что недавние изменения кода не сломали существующую функциональность. Это как убедиться, что ремонт тормозов автомобиля каким-то образом не сломал фары.

Ключевые Характеристики

• Всесторонний: Тестирует все приложение
• Документированный: Формальные тест-кейсы
• Времязатратный: Часы-дни
• Автоматизированный: Должен быть высоко автоматизирован
• Повторяющийся: Запускается часто (каждый спринт, каждый релиз)
• Накопительный: Набор тестов растет со временем

Что Покрывает Regression Testing

• ✅ Вся существующая функциональность
• ✅ Ранее исправленные баги (чтобы убедиться, что они не повторяются)
• ✅ Точки интеграции
• ✅ Критические бизнес-процессы
• ✅ Граничные случаи и пограничные условия

Рабочий Процесс Тестирования из Реального Мира

Сценарий: Добавлена новая функция - “Функциональность Списка Желаний”

Фаза 1: Smoke Testing (30 мин)

✓ App все еще загружается
✓ Login все еще работает
✓ Основные функции доступны
✓ Нет критических падений

Результат: ✅ Сборка стабильна, продолжить

Фаза 2: Feature Testing (2 дня)

Тест новой функции Списка Желаний:
✓ Добавить товары в список желаний
✓ Удалить товары
✓ Просмотреть страницу списка желаний
✓ Переместить товар из списка желаний в корзину
✓ Поделиться списком желаний
✓ Постоянство списка желаний

Результат: ✅ Функция работает, найдено 3 небольших бага

Фаза 3: Sanity Testing (1 час)

После исправления багов:
✓ Проверить, что 3 бага решены
✓ Повторно протестировать затронутые области
✓ Быстрая проверка связанных функций

Результат: ✅ Баги исправлены, нет очевидных проблем

Фаза 4: Regression Testing (1 день автоматизированно)

Запустить полный набор регрессии (450 тестов):
✓ Все тесты аутентификации прошли
✓ Все тесты корзины прошли
✓ Все тесты checkout прошли
✗ 2 теста поиска продуктов провалились (требуется расследование)

Результат: ⚠️ Найдено 2 регрессии в поиске, нужны исправления

Быстрое Руководство по Принятию Решений

Когда Следует Запускать…

Smoke Testing?

• ✅ Развернута новая сборка
• ✅ Начало дня (проверить окружение)
• ✅ CI/CD пайплайн (автоматизированно)
• ✅ Перед выделением QA ресурсов

Sanity Testing?

• ✅ Развернуто исправление бага
• ✅ Небольшое изменение конфигурации
• ✅ Применен hot fix
• ✅ Нужна быстрая проверка

Regression Testing?

• ✅ Перед релизом (обязательно)
• ✅ Конец спринта
• ✅ После крупных изменений кода
• ✅ После рефакторинга
• ✅ Интеграция новых библиотек

Заключение

Все три типа тестирования служат критическим, но различным целям:

Полный Поток Тестирования:

Новая Сборка → Smoke Test → Feature Test → Sanity Test (если есть исправления) → Regression Test → Релиз

Понимание того, когда и как использовать каждый тип, сделает ваше тестирование более эффективным, позволит обнаруживать баги раньше и обеспечит релизы более высокого качества.