Какие кейсы добавлял в Critical Path

Кейсы, добавляемые в Critical Path (Критический путь)

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

1. Основная бизнес-логика продукта

Это сценарии, без которых продукт теряет свою ценность для пользователя.

• Создание основного объекта/сущности (например, создание заказа в e-commerce, отправка сообщения в мессенджере).
• Оплата или финансовые транзакции (процесс оплаты, отмена, возврат средств).
• Аутентификация и авторизация (вход в систему под разными ролями, восстановление пароля).
• Поиск и отображение ключевых данных (поиск товара, просмотр деталей профиля).

2. Интеграции с критическими внешними системами

Проверка взаимодействия с системами, отказ которых парализует работу.

• Платежные шлюзы (например, Stripe, PayPal).
• Сервисы аутентификации (OAuth-провайдеры, Active Directory).
• Внешние API для данных (геолокация, проверка документов).

3. Миграции и совместимость данных

Особенно важны для продуктов с обновлениями БД или долгой историей.

• Обновление схемы базы данных без потери данных.
• Конвертация старых данных в новый формат.
• Совместимость с предыдущими версиями API (backward compatibility).

4. Критические пользовательские сценарии (Happy Path)

Позитивные сценарии, которые чаще всего выполняются пользователем.

Пример (e-commerce):
Feature: Critical Path - Order Creation
  Scenario: Successful order placement by registered user
    Given User is logged in
    And User has items in the cart
    When User completes checkout with valid payment details
    Then Order is confirmed
    And Order appears in user's history
    And Inventory is updated

5. Безопасность и конфиденциальность данных

Кейсы, защищающие от уязвимостей, которые могут привести к утечкам.

• Доступ к данным без авторизации (попытка получить чужие данные через API).
• Инъекции (проверка на SQL-инъекции в поисковых полях).
• Хранение чувствительных данных (пароли, токены) в зашифрованном виде.

6. Производительность и доступность критичных операций

Проверка, что ключевые операции укладываются в SLA.

• Время загрузки главной страницы (должно быть < 3 секунд).
• Отклик API для часто используемых эндпоинтов (например, /api/products).
• Доступность системы под нагрузкой (на базовом уровне).

7. Мультиплатформенность (если применимо)

Для кросс-платформенных продуктов.

• Критичный функционал на разных ОС (Windows, macOS, iOS, Android).
• Совместимость с основными браузерами (Chrome, Firefox, Safari).

Пример структуры Critical Path в тестовом менеджменте:

Critical Path v2.1 для FinTech App:
  - Аутентификация:
      - Вход по логину/паролю
      - Вход через 2FA
      - Блокировка после 5 неудачных попыток
  - Транзакции:
      - Перевод между своими счетами
      - Внешний перевод с подтверждением по SMS
      - Просмотр истории транзакций
  - Безопасность:
      - Сессия истекает после 15 минут неактивности
      - Невозможность SQL-инъекции в поиске по истории
  - Интеграции:
      - Получение курсов валют от внешнего провайдера
      - Отправка push-уведомлений о транзакции

Как я определяю, что добавить в Critical Path:

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

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