Когда сборка приложения после правок падает уже на экране логина, первым делом проверяют именно санити — быстрый набор проверок, который за пару минут показывает, жив ли продукт в принципе. Термин sanity check пришёл из английского языка и дословно означает «проверка здравомыслия»: инженер убеждается, что система ведёт себя разумно и её вообще имеет смысл тестировать глубже.
Понятие используется не только в QA. В программировании санити-проверкой называют валидацию входных данных, в системном администрировании — контроль базовых параметров сервера, а в разговорной речи разработчиков — любую быструю проверку «на адекватность» результата. В этой статье разберём все значения термина, покажем примеры и объясним, чем санити отличается от смоук-тестирования.
Определение термина санити
Санити (от англ. sanity — «здравомыслие, вменяемость») — это поверхностная проверка, цель которой ответить на один вопрос: работает ли система на базовом уровне после изменений. Глубокий анализ здесь не проводится — тестировщик или разработчик лишь убеждается, что критические функции не сломаны.
Ключевая черта санити — узкий фокус. Проверяется не весь продукт, а конкретный участок, который затронули правки. Если исправили расчёт скидки в корзине, санити затронет корзину и оформление заказа, но не раздел новостей.
Санити — это не полноценное тестирование, а быстрый фильтр: пропускает ли сборка дальше или её нужно вернуть на доработку немедленно.
Где применяется термин
Слово «санити» встречается в нескольких профессиональных контекстах, и смысл везде близкий, но не идентичный.
- 🧪 QA и тестирование — узкий набор проверок после небольших изменений или багфиксов.
- 💻 Программирование — sanity check входных данных: например, возраст не может быть отрицательным, а дата окончания не может быть раньше даты начала.
- 🖥️ Администрирование — быстрая проверка сервисов: отвечает ли сервер, доступна ли база данных, не переполнен ли диск.
- 📊 Аналитика данных — контроль адекватности выгрузок: нет ли в отчёте невозможных значений или пустых обязательных полей.
Во всех случаях логика одна: прежде чем тратить ресурсы на глубокую работу, нужно убедиться, что объект проверки вообще в рабочем состоянии.
Санити-тестирование в QA
В тестировании ПО санити-чек выполняют после получения нового билда с незначительными изменениями. Задача — подтвердить, что заявленный баг исправлен и правки не разрушили связанную функциональность. Обычно на это уходит от нескольких минут до пары часов в зависимости от масштаба продукта.
Характерные признаки санити-тестирования:
- ⚡ Скорость — выполняется быстро, без развёрнутой документации и тест-кейсов.
- 🎯 Узкий охват — проверяется только затронутая правками область.
- 🚪 Решение «проход/блок» — результат определяет, допускается ли сборка к дальнейшей работе.
- 🔄 Регулярность — запускается при каждой новой сборке с точечными изменениями.
Чем санити отличается от смоук-тестирования
Эти два термина постоянно путают, и даже внутри команд границы могут размываться. Классическое различие выглядит так.
| Критерий | Смоук-тест | Санити-тест |
|---|---|---|
| Цель | Убедиться, что сборка стабильна в целом | Проверить конкретные правки |
| Охват | Широкий, все ключевые модули | Узкий, затронутая область |
| Когда проводится | На новой сборке до начала работ | После багфиксов и мелких изменений |
| Документация | Часто формализован, есть чек-листы | Обычно без тест-кейсов |
Проще говоря: смоук отвечает на вопрос «жива ли сборка», а санити — «работает ли то, что мы чинили». На практике в небольших командах эти проверки нередко объединяют в один быстрый прогон, и это допустимо, если все понимают, что именно проверяется.
⚠️ Внимание: не подменяйте санити-проверкой полноценное регрессионное тестирование. Санити показывает только отсутствие явных поломок — скрытые дефекты в смежных модулях оно не выявит.
Как провести санити-проверку: порядок действий
Универсального чек-листа не существует — набор шагов зависит от продукта и характера правок. Но общий порядок действий выстраивается одинаково.
☑️ Базовый чек-лист санити-проверки
Сначала воспроизведите сценарий, в котором был найден дефект, и убедитесь, что он устранён. Затем пройдите один-два смежных сценария: например, если чинили оплату картой, проверьте ещё и отмену заказа. В конце посмотрите логи приложения и сервера — свежие ошибки там часто видны раньше, чем в интерфейсе.
Если проверка провалена, сборку возвращают разработчику с описанием проблемы. Тратить время на остальные тесты в этой ситуации бессмысленно.
Фиксируйте результат санити короткой записью: версия сборки, что проверяли, итог. Это займёт минуту, но избавит команду от вопросов «а это точно проверяли?» при следующем релизе.
Санити-чек в коде и данных
В программировании sanity check — это защитная проверка значений перед их использованием. Классический пример на псевдокоде:
if (age < 0 || age > 150) {
return error("Некорректное значение возраста");
}
Такие проверки не заменяют полноценную валидацию, но отсекают заведомо абсурдные данные на раннем этапе. Это дешёвая страховка: одна строка кода предотвращает падение расчётов или порчу данных в базе.
В аналитике санити-чек выгрузки может включать контроль количества строк, проверку на дубликаты ключей и поиск значений за пределами допустимого диапазона. Конкретный набор зависит от структуры данных и требований предметной области.
Откуда пошёл термин
Выражение sanity check использовалось в инженерии и математике задолго до появления современного QA — так называли быструю прикидку результата «на здравый смысл», чтобы отсеять грубые ошибки в расчётах. В IT термин закрепился вместе с практиками smoke testing и sanity testing в процессе разработки ПО.
⚠️ Внимание: санити-чек входных данных — не замена полноценной валидации и защите от атак. Проверка «возраст больше нуля» не спасёт от SQL-инъекции или переполнения буфера; для безопасности нужны отдельные механизмы.
Типичные ошибки при санити-проверках
Первая ошибка — превращать санити в многочасовой прогон. Если проверка занимает полдня, это уже не санити, а регрессия, и стоит пересмотреть её состав. Вторая ловушка — проверять только исправленный баг, игнорируя смежные сценарии: правки редко живут в вакууме.
Третья проблема — отсутствие любой фиксации результатов. Без записи о том, что и на какой сборке проверялось, команда теряет контекст, а при повторении дефекта приходится начинать разбор с нуля.
Хорошая санити-проверка — короткая, сфокусированная на правках и задокументированная хотя бы одной строкой результата.
FAQ: частые вопросы о санити
Что значит «прогнать санити» простыми словами?
Это значит быстро проверить, что система или функция работает на базовом уровне: приложение открывается, исправленная функция выполняет свою задачу, явных поломок нет. Глубокий анализ при этом не проводится.
Кто должен выполнять санити-тестирование?
Обычно это делает тестировщик, но в небольших командах санити-проверку может проводить и сам разработчик после правок, и аналитик перед демонстрацией результата. Важно не «кто», а то, что проверка выполнена и её результат зафиксирован.
Можно ли автоматизировать санити-проверки?
Да, типовые санити-сценарии часто автоматизируют и включают в конвейер сборки: автотесты запускаются на каждом билде и блокируют его при падении. Однако точечную проверку свежего багфикса иногда быстрее выполнить вручную.
Чем санити отличается от регрессионного тестирования?
Регрессия — полная проверка всего продукта на предмет того, не сломали ли изменения что-то ещё. Санити — короткая проверка только затронутой области. Санити не заменяет регрессию, а предшествует ей или идёт вместо неё при мелких правках.
Что делать, если санити-проверка провалена?
Зафиксируйте проблему: версия сборки, шаги воспроизведения, фактический результат. Верните сборку разработчику на доработку — продолжать тестирование заведомо сломанного билда не имеет смысла, это лишняя трата времени команды.