Тест-анализ требований сервиса

Тест-анализ требований сервиса — это ранняя проверка того, что сервис можно спроектировать, реализовать, поддерживать и проверить. В контексте SJM требованием является не только user story или BRD, но и шаг карты, BPMN-ветка, SLA-правило, KB-статья, шаблон ответа, workflow-статус, интеграционный контракт и правило мониторинга.

Главная идея из SJM Source - Куликов Базовый курс 2023: чем раньше найден дефект в требованиях, тем дешевле его исправить. Для сервисной модели это особенно важно, потому что плохое требование превращается не только в баг приложения, но и в неверный статус, сломанную маршрутизацию, бесполезную базу знаний или неразрешимый конфликт между командами.

Что проверять

Свойство	Как ломается в сервисе	Как улучшить
Завершённость	описан happy path, но не описаны SLA, исключения, ручные обходы, уведомления или поддержка	добавить missing scenarios, fallback, escalation, owner, monitoring signal
Атомарность	в одном пункте смешаны действие клиента, решение риск-службы и ответ поддержки	разбить на отдельные требования, статусы или BPMN-задачи
Непротиворечивость	SJM говорит одно, workflow другое, KB третье	сверить SJM, BPMN, CRM/workflow, KB и SLA как единую модель
Недвусмысленность	“быстро”, “удобно”, “в разумный срок”, “при необходимости”	заменить на измеримое правило, критерий приёмки или ссылку на стандарт
Выполнимость	целевой путь красивый, но нет данных, интеграции, роли или бюджета	провести feasibility review с IT, операциями, поддержкой и владельцем сервиса
Актуальность	правило осталось от старого процесса, но попало в новую модель	завести дату пересмотра и owner для изменяемых правил
Прослеживаемость	непонятно, из какого требования взялся статус или тест	связать SJM-шаг с требованием, BPMN, test case, defect, KB и метрикой
Модифицируемость	изменение SLA требует правки десятка несвязанных документов	убрать дубли, сделать source of truth и ссылки между артефактами
Ранжирование	команда тратит силы на малозначимые детали, а критичный сценарий не проверен	указать importance, urgency, stability и customer harm
Проверяемость	нельзя объективно сказать, сработал сервис или нет	добавить acceptance criteria, oracle и evidence

Схема прослеживаемости

flowchart LR
    A[Обещание сервиса] --> B[SJM шаг]
    B --> C[BPMN задача или статус]
    C --> D[Требование]
    D --> E[Критерий приёмки]
    E --> F[Test oracle]
    F --> G[Чек-лист или тест-кейс]
    G --> H[Evidence: лог, тикет, SLA, CRM]
    H --> I[Дефект или готовность]
    I --> J[Change request]
    J --> B

Техники проверки

Техника	Как применять к сервисной модели
Walkthrough	автор SJM/BPMN проходит карту с поддержкой, IT, рисками и владельцем сервиса
Technical review	разные роли проверяют свою плоскость: данные, интеграции, workflow, SLA, compliance, support
Inspection	использовать для критичных сервисов, миграций, регуляторных процессов и передачи на сопровождение
Вопросы	формулировать так, чтобы ответ улучшал модель: “какой статус увидит клиент через 15 минут?”, а не “статус нормальный?”
Пробные чек-листы	если по требованию невозможно быстро придумать проверку, требование, вероятно, непроверяемо
Моделирование поведения	мысленно пройти сервис в ролях клиента, первой линии, back-office, IT и владельца сервиса
Схемы и прототипы	использовать SJM, BPMN, state diagram, sequence diagram и mock UI, чтобы выявить несостыковки

Вопросы для service review

• Что именно обещает сервис клиенту и как клиент поймёт результат?
• Какой статус является клиентским, а какой внутренним?
• Где source of truth для статуса, срока, решения и коммуникации?
• Что произойдёт при timeout, отказе интеграции, дубле, ручной доработке и повторном обращении?
• Какие данные видит первая линия и чего она не должна видеть?
• Какое событие запускает SLA timer и какое событие его останавливает?
• Какой oracle подтверждает, что шаг выполнен корректно?
• Какое evidence останется после прохождения шага?
• Кто владелец дефекта, если проблема не в коде, а в маршрутизации, KB или регламенте?
• Что должно обновиться после изменения: SJM, BPMN, workflow, KB, monitoring, regression set?

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

• У каждого критичного шага SJM есть ожидаемый результат.
• Для каждого ожидания указан oracle: требование, SLA, KB, регламент, лог, CRM, system of record.
• Нет слов-индикаторов двусмысленности без чисел, критериев или ссылок.
• Исключения описаны отдельно от happy path.
• Поддержка и сопровождение участвуют в review до запуска.
• Есть traceability от требования до теста, дефекта и change request.
• Высокорисковые требования получили больший тестовый и review-фокус.
• Изменяемые требования имеют owner и правило пересмотра.

Советы

• Плохое требование лучше вскрыть вопросом, чем “героически” компенсировать тестированием после разработки.
• Для SJM полезнее один проверяемый критерий приёмки, чем страница красивого описания сервиса.
• Если у команды нет общего словаря статусов, сначала чинить словарь, потом рисовать target-state.
• Требование к сервису должно быть полезно не только разработчику, но и поддержке, QA, владельцу процесса и тому, кто будет разбирать инцидент.

Источники

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