Что исследовал при Sanity тестировании

Исследуемая область при Sanity тестировании

При выполнении Sanity тестирования (или проверки работоспособности) я, как QA Engineer, фокусируюсь на ограниченном, но критически важном наборе функций, чтобы убедиться, что основные сценарии работы приложения остаются стабильными после внесённых изменений. Это неглубокое, но целенаправленное исследование, которое отвечает на вопрос: «Можно ли продолжать более глубокое тестирование?». Вот что я исследую в первую очередь.

Ключевые направления исследования

• Целостность основных пользовательских путей (Core User Journeys): Я проверяю, что ключевые, наиболее часто используемые сценарии «счастливого пути» выполняются от начала до конца без фатальных ошибок. Например:

    *   В интернет-магазине: вход в учётную запись → поиск товара → добавление в корзину → начало процесса оформления заказа.
    *   В банковском приложении: авторизация → просмотр баланса → выполнение простого перевода.

• Работоспособность исправленного дефекта или новой функции: Если Sanity-тест запущен после фикса конкретного бага, я досконально проверяю именно этот сценарий и его ближайшее окружение. Если была добавлена новая кнопка — я проверю, что она отображается, кликабельна и выполняет свою базовую функцию.
• Отсутствие критических регрессионных ошибок: Я целенаправленно исследую области приложения, которые непосредственно связаны с внесёнными изменениями, на предмет появления новых, серьёзных проблем. Используется анализ зависимостей (dependency analysis) и оценка воздействия (impact analysis).
• Стабильность системы в целом: Быстрая проверка того, что приложение запускается, не «падает» на основных экранах, и что нет проблем с доступностью серверов или API. Это проверка «дышит» ли система.

Пример практического исследования

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

Что я буду исследовать в рамках Sanity Check:

1. Базовый сценарий: Открыть существующую задачу → нажать «Редактировать» → изменить текст заголовка → сохранить. Убедиться, что изменения сохраняются и отображаются.
2. Смежные области:

    *   Редактирование описания задачи (та же форма, но другое поле).
    *   Создание новой задачи (использует тот же компонент ввода заголовка).

1. Критическая регрессия: Проверить, не сломалась ли при этом функция удаления задачи (которая находится на том же экране) или фильтрации по заголовку.

Пример кода для автоматизированного Sanity-теста (если он есть в рамках «быстрой проверки»):

# Пример на Python + pytest для тестирования ключевого сценария
import pytest

def test_sanity_edit_task_title(mobile_app, test_task):
    """
    Sanity-тест: Проверка базового редактирования заголовка задачи.
    """
    # 1. Открыть существующую задачу
    task_screen = mobile_app.open_task_by_id(test_task.id)

    # 2. Начать редактирование и изменить заголовок
    new_title = "Отредактированный заголовок " + test_task.id
    task_screen.click_edit()
    task_screen.update_title(new_title)
    task_screen.save()

    # 3. Проверить, что изменения применились
    assert task_screen.get_title() == new_title, "Заголовок задачи не обновился после редактирования"
    # 4. (Опционально) Проверить, что задача видна в общем списке с новым заголовком
    home_screen = mobile_app.go_to_home()
    assert home_screen.is_task_present_with_title(new_title), "Задача с новым заголовком не найдена в списке"

Отличие от Smoke-тестирования

Важно разграничивать:

• Smoke-тестирование — это широкий и поверхностный чек всех ключевых модулей системы после сборки. «Дымит ли система в целом?».
• Sanity-тестирование — это узкий и более глубокий чек конкретной функциональности после изменений. «Здравомысленна ли конкретная новая функция или фикс?».

Вывод

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