Что такое sanity-тестирование?
Sanity-тестирование (тестирование «на вменяемость») — узкая, сфокусированная проверка после конкретного изменения — обычно исправления бага или незначительного обновления — чтобы убедиться, что изменение работает корректно и не сломало очевидным образом связанную функциональность. В отличие от smoke, который широко проверяет стабильность всей сборки, sanity фокусируется на конкретной области.
Разница: Smoke-тестирование — врач проверяет жизненные показатели (пульс, давление, температура) для общей оценки здоровья. Sanity-тестирование — врач проверяет, работает ли конкретное лекарство, прописанное вчера.
После исправления бага в расчёте оплаты sanity-тестирование проверяет:
- Конкретный баг действительно исправлен
- Близкая функциональность по-прежнему работает
- Область вокруг исправления стабильна
Sanity НЕ проверяет всё приложение. Не смотрит на вход, поиск или несвязанные функции.
Полное сравнение: Smoke vs Sanity vs Регрессия
| Характеристика | Smoke | Sanity | Регрессия |
|---|---|---|---|
| Цель | Сборка стабильна? | Конкретный fix работает? | Что-то ещё сломалось? |
| Масштаб | Широкий, поверхностный | Узкий, глубокий | Широкий, глубокий |
| Когда | После каждой сборки | После конкретного fix/изменения | Перед релизом |
| Длительность | 10-15 минут | 15-30 минут | Часы-дни |
| Автоматизация | Обычно автоматизированный | Обычно ручной | Микс |
| Кто | QA или CI/CD | QA-инженер | QA-команда |
| Аналогия | Общий осмотр | Проверка действия лекарства | Полное обследование |
Когда использовать sanity-тестирование
После исправления бага
Баг-репорт: «Расчёт скидки показывает 12% вместо 10% для заказов свыше $100.» Разработчик исправляет. Перед полной регрессией:
- Проверить точный сценарий из баг-репорта — теперь 10%
- Протестировать несколько связанных сценариев скидок
- Убедиться, что расчёт итоговой суммы не сломался
После незначительного обновления
Запрос: «Добавить кнопку “Очистить всё” в центр уведомлений.»
- Кнопка появляется
- Клик очищает все уведомления
- Индивидуальное закрытие уведомлений работает
- Счётчик обновляется корректно
После изменения конфигурации
DevOps увеличивает пул подключений к БД с 10 до 50:
- Приложение подключается к БД
- Несколько ресурсоёмких операций работают
- Нет ошибок таймаута
Когда НЕ использовать
- Как замену регрессии. Это быстрая проверка, не всесторонняя верификация.
- Для крупных функциональных релизов. Значительные изменения требуют системного и регрессионного тестирования.
- Когда масштаб изменения неясен. Если не знаете, на что влияет — тестируйте шире.
Как выполнять sanity-тестирование
- Прочитать описание изменения — Что изменено и почему?
- Воспроизвести оригинальную проблему (при bug fix) — Подтвердить исправление
- Протестировать связанную функциональность — 3-5 близких сценариев
- Проверить очевидные побочные эффекты — UI корректный? Соседние функции работают?
- Быстрое решение — Продолжать тестирование или вернуть разработчику?
Мышление sanity-тестирования
Требуется опытное суждение. В отличие от скриптованных тестов, sanity полагается на знание тестировщика:
- Определить «связанную функциональность» для данного изменения
- Распознать, когда что-то «выглядит неправильно» без формального тест-кейса
- Знать, когда остановиться, а когда эскалировать
Упражнение: Определите — Smoke, Sanity или Регрессия
Для каждого сценария определите подходящий тип тестирования:
- Новая сборка развёрнута в QA-окружение утром
- Разработчик исправил баг, где «Экспорт в CSV» скачивал пустой файл
- Команда готовит релиз в продакшен на следующей неделе
- DevOps мигрировали приложение на новый сервер
- Разработчик изменил алгоритм сортировки для результатов поиска
- Страницу входа перерисовали с новым брендингом без изменения функциональности
- Применён критический патч безопасности к модулю аутентификации
- Ночная сборка завершилась в 3 часа ночи
Подсказка
Спросите: Я проверяю, работает ли вся сборка (smoke), работает ли конкретный fix (sanity), или всё по-прежнему работает перед релизом (регрессия)?Решение
Smoke — Новая сборка в QA. Проверить стабильность перед началом тестирования.
Sanity — Конкретный баг исправлен. Проверить fix, протестировать связанные сценарии экспорта, убедиться в других форматах.
Регрессия — Предрелизное тестирование требует всесторонней проверки.
Smoke — Миграция сервера — инфраструктурное изменение. Проверить, что приложение работает на новом сервере.
Sanity — Изменён конкретный алгоритм. Проверить точность результатов, протестировать различные запросы.
Sanity + Направленная регрессия — Редизайн UI без функциональных изменений. Sanity — вход работает с новым дизайном. Затем направленная регрессия потока входа.
Sanity, затем Регрессия — Патчи безопасности — высокий риск. Сначала sanity аутентификации. Затем полная регрессия модуля.
Smoke — Ночные сборки должны запускать автоматические smoke-тесты.
Рабочий процесс sanity-тестирования
прошёл?} SMOKE -->|Нет| REJECT[Отклонить сборку] SMOKE -->|Да| SANITY[Sanity-тестирование
Проверить изменение] SANITY -->|Fix работает| REGRESSION[Перейти к регрессии] SANITY -->|Fix не работает| RETURN[Вернуть разработчику] SANITY -->|Новые проблемы| TRIAGE[Оценить:
блокировать или продолжить?]
Профессиональные советы
Совет 1: Sanity — про уверенность, не покрытие. Вы не ищете каждую возможную проблему. Вы строите достаточную уверенность, что fix разумен.
Совет 2: Документируйте результаты. Хоть sanity и неформальный, документируйте, что проверили. Когда баг всплывёт в продакшене — нужно знать, что было проверено.
Совет 3: Ограничивайте время. 15-30 минут максимум. Если не можете проверить за это время — fix сложнее, чем ожидалось.
Ключевые выводы
- Sanity — узкая, сфокусированная проверка конкретного изменения или bug fix
- Отличается от smoke (широкая стабильность) и регрессии (всесторонняя проверка)
- Выполняется вручную опытными QA с использованием суждения и знания системы
- Уместно после bug fix, незначительных обновлений и изменений конфигурации
- Не заменяет регрессию — быстрая проверка перед более глубоким тестированием
- Ограничивать 15-30 минутами и документировать результаты