По каким критериям отбираются сценарии в Critical Path

Критерии отбора сценариев для Critical Path (Критического пути)

Выделение Critical Path — это одна из ключевых стратегий управления рисками и оптимизации процесса тестирования, особенно в условиях нехватки времени и ресурсов. Критический путь представляет собой минимальный набор наиболее важных сценариев, выполнение которых необходимо для того, чтобы убедиться, что основная бизнес-ценность продукта работоспособна и может быть передана пользователю. Отбор сценариев в этот набор — ответственная задача, основанная на аналитическом подходе, а не на интуиции.

Я, как QA Lead, руководствуюсь следующими ключевыми критериями, которые можно разделить на три основные категории: бизнес-критерии, технические критерии и критерии, основанные на данных.

1. Бизнес-критерии (Наиболее важные)

Эти критерии напрямую связаны с ценностью продукта для конечного пользователя и заказчика.

• Частота использования (Frequency of Use): Сценарии, которые выполняет >80% пользователей при каждом посещении системы. Например, для интернет-магазина это: вход в аккаунт, просмотр каталога, добавление товара в корзину, оформление и оплата заказа. Отказ этих функций делает продукт бесполезным.
• Ключевая бизнес-логика (Core Business Logic): Сценарии, реализующие основную цель продукта. Для банковского приложения — это перевод средств, для стриминговой платформы — воспроизведение видео. Мы проверяем «счастливый путь» (happy path) и основные альтернативные потоки для этих операций.
• Влияние на доход (Revenue Impact): Функции, напрямую генерирующие доход или удерживающие платежеспособных клиентов. Сбои в платежном шлюзе, системе подписок или тарификации критичны для бизнеса.
• Соответствие нормативным требованиям (Compliance): Обязательные для выполнения сценарии, продиктованные законами (например, GDPR, PCI DSS) или отраслевыми стандартами. Их некорректная работа ведет к юридическим рискам и штрафам.

2. Технические критерии

Эти критерии оценивают уязвимость системы с точки зрения архитектуры и истории разработки.

• Сложность и связанность модулей (High Complexity & Coupling): Функции, затронутые последними крупными архитектурными изменениями (рефакторинг, миграция БД) или построенные на сложной, слабо документированной логике. Они имеют повышенную вероятность регрессии.
• История дефектов (Defect Density): Модули с наибольшим количеством багов, обнаруженных в продакшене (production bugs), или с повторяющимися ошибками в смежных областях. Это индикатор нестабильности.
• Критичность интеграций (Critical Integrations): Сценарии, затрагивающие интеграцию с внешними системами, отказ которых парализует работу (платежные системы, SMS-шлюзы, микросервисы ядра). Мы проверяем как успешные сценарии, так и обработку ошибок со стороны внешнего API.

3. Критерии, основанные на данных (Data-Driven)

Здесь мы опираемся на метрики и аналитику, а не на предположения.

• Анализ логов продакшена (Production Log Analysis): Поиск в логах ошибок (exceptions, 5xx HTTP-статусы) и самых популярных маршрутов (endpoints). Сценарии, покрывающие проблемные и популярные endpoints, автоматически попадают в Critical Path.
• Мониторинг и алерты (Monitoring & Alerts): Если в системе есть инциденты, которые уже срабатывали и приводили к уведомлениям команды (PagerDuty, Opsgenie), их воспроизводящие сценарии включаются в обязательную проверку.
• Карта покрытия изменений (Code Churn & Impact Analysis): Использование данных из систем контроля версий (например, Git) для выявления наиболее часто меняющихся в последнем спринте/релизе файлов. Тесты для этих областей должны быть в приоритете.

Практический пример и вывод

На практике отбор — это всегда взвешивание всех критериев. Допустим, мы готовим Critical Path для релиза интернет-банка.

1. Сначала берем сценарии по бизнес-критериям: логин, просмотр баланса, перевод между своими счетами, перевод на карту другого банка.
2. Затем накладываем технические критерии: если в текущем спринте полностью переписывался модуль переводов, мы усиливаем его проверку, добавляя граничные значения и проверки безопасности.
3. Наконец, проверяем данные: если в логах прошлой недели были ошибки при работе с определенным банком-корреспондентом, включаем соответствующий кейс.

# Пример сценария Critical Path для интернет-банка (упрощенно)
Feature: Критический путь - Денежные переводы
  Как авторизованный клиент,
  Я хочу выполнять переводы,
  Чтобы управлять своими финансами.

  @critical_path @smoke
  Scenario: Успешный перевод между своими счетами
    Given Я авторизован как пользователь "Иван Петров"
    And У меня есть текущий счет "₽" с балансом более 1000
    And У меня есть сберегательный счет "₽"
    When Я перевожу 500 ₽ с текущего счета на сберегательный
    Then Баланс текущего счета уменьшился на 500 ₽
    And Баланс сберегательного счета увеличился на 500 ₽
    And В истории операций отображается запись о переводе

  @critical_path @integration
  Scenario: Обработка ошибки при внешнем переводе (недостаточно средств)
    Given Я авторизован как пользователь "Иван Петров"
    And У меня есть текущий счет "₽" с балансом 100
    When Я пытаюсь перевести 200 ₽ на карту другого банка "XXX"
    Then Я вижу сообщение "Недостаточно средств на счете"
    And Баланс моего счета остался 100 ₽

Итог: Критический путь — это не статичный список, а динамическая живая документация, которая пересматривается перед каждым крупным релизом или даже деплоем. Его цель — за минимальное время (например, 10-15 минут прогона) дать максимальную уверенность в том, что система работоспособна и готова к использованию. Фокус всегда на том, что принесет наибольший ущерб бизнесу или наибольшее неудобство пользователю в случае сбоя.