Чек-листы и тест-кейсы сервиса

Чек-лист в сервисной модели — это набор идей проверок. Тест-кейс — более формальная проверка с предусловиями, шагами, входными данными и ожидаемым результатом. Для SJM важно использовать оба уровня: чек-листы помогают быстро думать, тест-кейсы помогают повторяемо доказывать готовность.

Идея из SJM Source - Куликов Базовый курс 2023: чек-листы не обязаны быть подробными сценариями, но они должны быть логичными, структурированными, достаточно полными и неизбыточными. Тест-кейсы должны быть достаточно конкретными для выполнения, но не настолько зарегламентированными, чтобы становиться дорогими и хрупкими.

Как строить проверочное покрытие от SJM

flowchart TD
    A[SJM карта] --> B[Критичные клиентские ожидания]
    A --> C[Backstage и handoff]
    A --> D[Systems и data flow]
    A --> E[Support и KB]
    B --> F[Positive checks]
    B --> G[Negative checks]
    C --> H[Exception и routing checks]
    D --> I[Integration и data checks]
    E --> J[Support readiness checks]
    F --> K[Regression set]
    G --> K
    H --> K
    I --> K
    J --> K

Логики разбиения чек-листов

Логика	Когда полезна	Пример для сервиса
По сценариям клиента	для SJM и UAT	заявка создана, заявка отклонена, заявка зависла, клиент повторно обратился
По процессу	для BPMN и workflow	регистрация, классификация, эскалация, решение, закрытие, reopen
По системам	для интеграций и данных	CRM, система обращений, API, хранилище документов, уведомления
По риску	для ограниченного времени	high customer harm, high financial impact, compliance-sensitive
По статусам	для операционной модели	new, in_progress, waiting_customer, resolved, closed, reopened
По данным	для source of truth и reconciliation	клиент, продукт, заявка, документ, операция, SLA timer
По поддержке	для запуска и сопровождения	категория, очередь, KB, шаблон ответа, права первой линии, escalation path

Поля сервисного тест-кейса

Поле	Для чего нужно
ID	ссылка из release checklist, defect, regression set
Приоритет	помогает выбирать проверки при нехватке времени
SJM шаг	показывает, какую часть клиентского пути проверяем
Требование / oracle	объясняет, откуда взят ожидаемый результат
Сервисный компонент	канал, CRM, workflow, интеграция, KB, мониторинг, back-office
Заголовок	коротко описывает проверяемую ситуацию
Предусловия	роль, данные, статус, доступы, состояние интеграции
Входные данные	сегмент клиента, тип обращения, сумма, срок, канал, документ
Шаги	действия клиента, поддержки, системы или автоматической проверки
Ожидаемый результат	статус, сообщение, запись в логе, SLA-событие, тикет, уведомление
Evidence	где увидеть результат: CRM, лог, мониторинг, SLA-отчёт, скрин, запись обращения
Regression flag	надо ли повторять после релиза, hotfix или изменения правила
Owner	кто разбирает дефект: продукт, процесс, IT, поддержка, риск/compliance

Матрица проверок

Тип проверки	Что искать	Пример
Positive	нормальное прохождение ценного сценария	клиент создал обращение, получил понятный статус, SLA пошёл корректно
Negative	неправильные входы и отказные условия	неполные данные, недоступный документ, неверная категория, дубль
Boundary	границы правил	1 минута до SLA breach, ровно лимит суммы, последний день срока
Equivalence	группы, которые должны вести себя одинаково	типы клиентов, каналы, категории обращений, продуктовые сегменты
Exception	нестандартная ветка процесса	timeout интеграции, ручная проверка, повторное открытие, компенсация
Recovery	восстановление после сбоя	retry, fallback, reconciliation, клиентское уведомление после инцидента
Support readiness	готовность обслуживания	первая линия видит нужные поля, KB отвечает на вопрос, escalation работает

Баланс детализации

Слишком общий тест-кейс оставляет исполнителю слишком много догадок. Слишком детальный тест-кейс дорого поддерживать, особенно если интерфейс, workflow или интеграция часто меняются.

Практическое правило для сервиса:

• детали обязательны там, где без них невозможно воспроизвести проблему;
• детали можно обобщать там, где важна не конкретная кнопка, а проверяемое бизнес-состояние;
• expected result должен быть конкретнее steps, потому что именно он определяет качество;
• негативные проверки лучше не склеивать: один дефект — одна понятная причина и один owner;
• позитивные проверки можно объединять, если они отражают единый пользовательский путь.

Мини-шаблон чек-листа

## Чек-лист сервиса

- Цель проверки:
- Риск:
- Oracle:
- Сценарии:
  - [ ] Happy path
  - [ ] Неполные данные
  - [ ] Дубль
  - [ ] Timeout интеграции
  - [ ] Ручная обработка
  - [ ] Reopen
  - [ ] SLA breach / near breach
  - [ ] Клиентская коммуникация
  - [ ] Evidence в CRM/logs/SLA report

Практический чек-лист

• Чек-листы разделены по понятной логике, а не собраны в одну длинную простыню.
• У каждой проверки есть цель.
• Критичный path проверяется раньше косметических деталей.
• Есть positive, negative, boundary и exception checks.
• Для support-сценариев проверены CRM, routing, KB, SLA и шаблоны ответа.
• Regression set покрывает статусы, уведомления, интеграции и recovery.
• Тест-кейсы не дублируют друг друга без причины.
• Тест-кейсы можно выполнить человеком, который не участвовал в проектировании.

Источники

• SJM Source - Куликов Базовый курс 2023
• Тест-анализ требований сервиса
• Тестирование и качество сервисов
• Справочник понятий сервисной модели