methodology
Около 6 мин чтения
Практическое понятие — не выделено отдельной главой ISTQB, но широко используется в индустрии
См. также: ISTQB CTFL v4.0, глава 2.6 — Regression Testing and Confirmation Testing (смежная тема)
Smoke и Sanity — это два типа быстрого тестирования, которые решают одну задачу: не допустить трату ресурсов на детальное тестирование нерабочей сборки. Несмотря на внешнюю похожесть, это разные практики с разными целями, объёмом и местом в тестовом процессе.
Метафора: Smoke-тест — как проверить, включается ли автомобиль вообще. Sanity-тест — как проверить, что после замены двигателя тормоза всё ещё работают.
Smoke-тестирование (также называют build verification testing, build acceptance testing) — это минимальный набор тестов, который проверяет, что критически важные функции системы работают, и сборку можно принять для дальнейшего детального тестирования.
Название пришло из электроники: если при включении устройства идёт дым (smoke) — дальше тестировать бессмысленно.
Sanity-тестирование — это узконаправленное тестирование конкретной функции или области после внесения изменения (багфикс, хотфикс, небольшое изменение), чтобы убедиться, что изменение работает корректно и не сломало смежную логику.
| Критерий | Smoke | Sanity |
|---|---|---|
| Что проверяем | Стабильность сборки в целом | Корректность конкретного изменения |
| Объём | Широкий, но неглубокий | Узкий, но более детальный |
| Когда | Получена новая сборка | Исправлен дефект / внесено изменение |
| Охват | Основные функции всей системы | Конкретная функция + смежные |
| Документация | Часто автоматизирован, есть чек-листы | Обычно не формализован |
| Цель | Стоит ли вообще начинать тестирование? | Стоит ли передавать исправление дальше? |
| Ответ на вопрос | «Сборка не сломана?» | «Исправление работает?» |
| # | Тест-кейс | Ожидаемый результат |
|---|---|---|
| 1 | Открыть главную страницу | Страница загружается без ошибок |
| 2 | Авторизоваться | Успешный вход в систему |
| 3 | Найти товар через поиск | Результаты поиска отображаются |
| 4 | Добавить товар в корзину | Товар появляется в корзине |
| 5 | Открыть корзину | Страница корзины отображается |
| 6 | Оформить заказ (до оплаты) | Форма оформления доступна |
Всё это — 15–20 минут. Если хотя бы один шаг не проходит — сборка нестабильна, детальное тестирование не начинается.
Сценарий: Исправлен баг «НДС рассчитывается неправильно для товаров с нулевой ставкой»
| # | Тест-кейс | Ожидаемый результат |
|---|---|---|
| 1 | Товар с НДС 0% → сумма = 0 | ✅ НДС = 0 |
| 2 | Товар с НДС 20% → сумма = цена × 0.2 | ✅ НДС рассчитан верно |
| 3 | Смешанная корзина (0% + 20%) | ✅ НДС по каждой позиции верен |
| 4 | Итого с учётом НДС | ✅ Общая сумма корректна |
| Роль | Smoke | Sanity |
|---|---|---|
| QA-инженер / тестировщик | ✅ Основной исполнитель | ✅ Основной исполнитель |
| Разработчик | Может делать в CI/CD | Иногда делает перед передачей в QA |
| DevOps / SRE | Деплой + smoke-проверки | — |
| Менеджер | Утверждает критерии smoke | — |
В зрелых командах smoke-тесты автоматизированы и запускаются в CI/CD. Sanity чаще выполняется вручную, так как зависит от контекста конкретного изменения.
@sanity-tax, @sanity-cart| Критерий | Smoke | Sanity | Regression |
|---|---|---|---|
| Цель | Проверить стабильность сборки | Проверить конкретное изменение | Проверить отсутствие побочных эффектов |
| Объём | Вся система (поверхностно) | Область изменения (детальнее) | Вся система (детально) |
| Когда | Каждая новая сборка | После каждого изменения | После изменений / перед релизом |
| Автоматизация | Высокая | Средняя | Высокая |
| Длительность | 15–60 мин | 30–120 мин | Часы — дни |
| Тест-кейсы | Фиксированный набор | Зависит от изменения | Полный набор |