Какие тесты считаешь обязательными для прогона перед релизом?

Обязательные тесты перед релизом

Как QA Automation Engineer с многолетним опытом, я считаю, что перед релизом необходимо выполнить комплексную проверку, которая охватывает не только функциональную корректность, но и стабильность, безопасность и готовность системы к реальной нагрузке. Этот прогон — последний барьер перед выходом продукта к пользователям, поэтому он должен быть максимально полным и строгим.

Основные категории обязательных тестов

1. Критические функциональные тесты (Smoke & Sanity)

Это минимальный набор для проверки, что система «жива» и ключевые функции работают.

• Авторизация/аутентификация: доступ для основных ролей пользователей.
• Ядро бизнес-логики: например, создание заказа в e-commerce, расчет платежа в финтех-проекте.
• Критические пользовательские сценарии (Happy Path): типовые действия целевого пользователя.

# Пример: критический сценарий для API создания пользователя
import requests

def test_critical_user_create_smoke():
    url = "https://api.example.com/v1/users"
    payload = {"email": "test@release.com", "password": "securePass123"}
    headers = {"Authorization": "Bearer release-token"}
    
    response = requests.post(url, json=payload, headers=headers)
    assert response.status_code == 201
    assert "id" in response.json()
    assert response.json()["email"] == payload["email"]
    # Проверка, что пользователь реально создан и может авторизоваться
    auth_response = requests.post("https://api.example.com/v1/auth", json=payload)
    assert auth_response.status_code == 200

2. Регрессионные тесты ключевых модулей

Необходимо прогнать автотесты на модули, которые:

• Изменялись в текущем релизном цикле.
• Имеют высокую интеграционную связанность (например, модуль платежей, который затрагивает многие другие сервисы).
• Исторически были проблемными (согласно данным из баг,trackеров).

3. Интеграционные и API тесты

Проверка взаимодействия между сервисами, микросервисами или с внешними системами (платежные шлюзы, SMS-сервисы).

• Контрактные тесты (Pact) для проверки соглашений между потребителем и поставщиком API.
• Тесты на корректность ответов и ошибок API.

4. Тесты безопасности (Security)

• Базовая проверка авторизации и RBAC: доступно ли только тем, кому должно быть.
• Тесты на распространенные уязвимости: SQL-инъекция, XSS (для веба), несанкционированный доступ к данным.
• Валидация входных данных на границах системы.

5. Нагрузочные тесты (Performance)

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

• Тесты на пиковую нагрузку: имитация прогнозируемого максимального числа пользователей.
• Проверка критических метрик: время ответа API, потребление памяти, стабильность под нагрузкой.

// Пример конфигурации нагрузочного теста в JMeter (описание)
// 1. Thread Group: 100 пользователей, ramp-up 60 секунд.
// 2. HTTP Request: POST /api/checkout (критический путь).
// 3. Assertions: Response Time < 2000ms для 95% запросов.
// 4. Listeners: Aggregate Report для анализа результатов.

6. Тесты на отказоустойчивость и восстановление (Resilience)

• Тесты на деградацию внешних сервисов: что происходит, если платежный шлюз отвечает с ошибкой или временно недоступен?
• Проверка механизмов повторных попыток (retry) и откатов (rollback).
• Для контейнерных приложений — проверка перезапуска pod'ов.

7. Тесты совместимости (Compatibility)

• Кросс-браузерные тесты для веб-приложений (Chrome, Firefox, Safari последних стабильных версий).
• Тесты на мобильных устройствах/OS (если есть мобильное приложение или адаптивный веб).
• Тесты на разных разрешениях и ориентациях экрана.

8. Тесты данных и миграций (Data Integrity)

Если релиз включает миграции базы данных:

• Тесты на корректность скриптов миграции (на тестовых копиях prod-данных).
• Проверка консистентности данных после миграции.
• Тесты на rollback миграции (на случай срочного отката).

9. Документация и мониторинг

Это не совсем «тесты», но обязательные проверки:

• Актуальность релизной документации для поддержки и пользователей.
• Работоспособность ключевых метрик и алертов в мониторинге (Prometheus, Grafana, CloudWatch).
• Проверка логгирования: критические операции должны логироваться корректно.

Организация прогона

С технической стороны, этот прогон должен быть автоматизирован как минимум на 80%. Ключевые интеграционные, API и нагрузочные тесты обязательно выполняются автоматически. Неавтоматизированными могут остаться некоторые тесты совместимости (визуальная проверка на разных устройствах) и ад-hoc проверки сложных бизнес-сценариев.

Прогон должен выполняться на окружении, максимально близком к Production (Staging/Pre-Prod), с использованием копий реальных данных (обезличенных). Все обнаруженные дефекты, кроме тривиальных, обычно являются блокерами для релиза.

Философия подхода: перед релизом мы проверяем не только «что новое работает», но и «что старое не сломалось», а система в целом способна выдержать переход из состояния разработки в состояние реального использования.