Что мы проверяем при помощи Sanity

Что мы проверяем при помощи Sanity Testing?

Sanity Testing (или «проверка здравомыслия» / «быстрая проверка») — это узкий, поверхностный тест, выполняемый после получения новой сборки (build) или после выполнения значительных изменений в коде, чтобы убедиться, что ключевые, самые базовые функции системы работают «в общем и целом». Его главная цель — не глубокий анализ, а быстрое определение того, стоит ли продолжать более масштабное и дорогостоящее тестирование.

Основные цели Sanity Testing

• Определение стабильности сборки: Ответить на вопрос «Можно ли начинать полноценное тестирование на этой версии?».
• Выявление критических сбоев «на поверхности»: Найти очевидные, блокирующие дефекты, которые делают систему непригодной для дальнейшей проверки.
• Экономия времени и ресурсов: Не тратить часы на регрессионное тестирование или детальное функциональное тестирование, если система «сломана» в фундаментальных моментах.
• Проверка исправления конкретного дефекта: После фикса одного бага — убедиться, что исправление работает и не «сломало» очевидные связанные функции.

Конкретные области и примеры проверок в Sanity Test

На практике Sanity Testing проверяет самые базовые и критичные для работы системы сценарии. Вот что обычно включается в такой чек-лист:

1. Основные пользовательские пути (Happy Path для ключевых функций)

• Для веб-приложения: Возможность зайти на сайт, авторизоваться, увидеть главную страницу.

  # Пример простого sanity-скрипта для проверки авторизации
  import requests
  
  base_url = "https://example.com/api"
  login_data = {"username": "test_user", "password": "correct_password"}
  
  response = requests.post(f"{base_url}/login", json=login_data)
  assert response.status_code == 200, f"Login failed with status {response.status_code}"
  assert "token" in response.json(), "Auth token not received after login"
  print("Sanity check: Basic authentication PASSED")
  

• Для мобильного приложения: Приложение запускается, основные экраны отображаются, нет критичных крешей.
• Для API: Ответ основных эндпоинтов (GET /health, POST /auth) возвращает корректный статус (200, 401) и ожидаемую структуру данных.

2. Работоспособность исправленного функционала

Если сборка выходит для исправления конкретного бага, sanity тест фокусируется именно на этом:

• Баг #123: «Не работает кнопка „Сохранить“ в профиле».
• Sanity проверка: Зайти в профиль, изменить поле, нажать «Сохранить», убедиться, что данные сохранились и появилось сообщение об успехе.

3. Критичные интеграции и зависимости

• Проверка, что система может подключиться к основным внешним сервисам (база данных, платежный шлюз, email-сервис).
• Проверка, что основные конфигурационные файлы загружаются и применяются.

4. Визуально очевидные и блокирующие проблемы

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

Sanity Testing vs Smoke Testing: ключевое отличие

Часто эти термины смешивают, но есть важное различие:

• Smoke Testing («дымовое тестирование») — это более формализованный и полный набор проверок, охватывающий все основные функциональные модули системы. Он часто автоматизирован и выполняется на каждой новой сборке.
• Sanity Testing — более адресный и узкий. Он может выполняться не на каждой сборке, а, например, после конкретных изменений. Он менее формализован и часто проводится интуитивно, основываясь на знаниях тестировщика о самых «болевых» точках системы.

Аналогия: Smoke Testing — это проверка всех основных систем автомобиля (двигатель, тормоза, свет, передача) перед длительной поездкой. Sanity Testing — это быстрое убеждение, что автомобиль хотя бы заводится и колеса не отвалились, после того как вам только поменяли масло.

Практический подход: как проводить Sanity Testing

1. Создайте и поддерживайте короткий чек-лист (5-15 пунктов) для самых критичных функций вашего продукта.
2. Выполняйте его первым делом после получения новой версии для тестирования.
3. Если sanity тест провален — немедленно сообщите команде разработки. Не начинайте регресс, нагрузку или детальное тестирование.
4. Если sanity тест пройден — вы можете с уверенностью сказать, что сборка «стабильна для дальнейшего тестирования», и начать более глубокие проверки.

Пример чек-листа Sanity Testing для веб-приложения CRM:

• ✅ Приложение доступно по основному URL.
• ✅ Страница логина отображается.
• ✅ Вход с тестовыми учетными данными успешен.
• ✅ После логина отображается главный дашборд.
• ✅ Критичный модуль «Список клиентов» загружается и показывает хотя бы одну запись.
• ✅ Навигация между главным меню работает.

Таким образом, Sanity Testing — это наш первый и быстрый фильтр, который отвечает на фундаментальный вопрос: «Система в целом жива и функционирует?». Это не поиск мелких багов или проверка edge-cases, а валидация самой возможности продолжать тестовые активности. Его проведение экономически эффективно и предотвращает трату ресурсов на тестирование очевидно нерабочей версии продукта.