Тестирование и качество сервисов

Тестирование сервисов — это не только проверка интерфейса или кода. В сервисной модели тестируется способность организации доставить обещанный результат: через процесс, системы, людей, поддержку, статусы, SLA, уведомления, fallback и recovery.

Что это даёт в реальной работе

Делает требования проверяемыми.
Покрывает happy path, исключения, ошибки и деградации.
Связывает QA с поддержкой и сопровождением.
Помогает найти расхождения между целевым и фактическим процессом.
Даёт evidence для change requests.

Ключевые источники и идеи

Источник	Что взять для сервисной модели	Ограничение
ISTQB CTFL / Rex Black	общий словарь тестирования, test levels/types, static testing, defect management, risk-based testing, tools	открыт официальный syllabus; сохранена source card SJM Source - Rex Black ISTQB CTFL 2020
BBST / Kaner / Falk / Nguyen	test strategy, oracles, coverage, невозможность полного тестирования, осторожность с метриками дефектов	открыты Foundations; сохранена source card SJM Source - Канер Фолк Нгуен 2001
Ron Patton	базовая практическая школа software testing	нужен полный текст: `source_required`
Glenford Myers	психология тестирования, test-case design, inspections, regression	сохранена source card SJM Source - Myers Art of Software Testing 2011
Gerald Weinberg	ограничения “perfect software”, роль людей и ожиданий	нужен полный текст: `source_required`
Святослав Куликов	русскоязычная практическая база по требованиям, чек-листам, тест-кейсам, дефектам, RCA и автоматизации	обработан полный текст; сохранена source card SJM Source - Куликов Базовый курс 2023

Справочный слой

Справочный слой переводит тестирование из “проверить, что работает” в управление evidence о качестве сервиса. Для SJM это особенно важно: сервис ломается не только в коде, но и в статусах, маршрутизации, SLA, базе знаний, данных первой линии и восстановлении после ошибки.

Практический слой по Куликову

Материал Куликова полезен не как отдельный курс, а как практическая дисциплина оформления проверяемости сервиса:

Тест-анализ требований сервиса — как проверять SJM, BPMN, SLA, KB, workflow и требования до разработки.
Чек-листы и тест-кейсы сервиса — как превращать карту сервиса в structured coverage и regression set.
Дефекты сервиса и RCA — как описывать проблемы так, чтобы их можно было исправить и не повторять.
Автоматизация проверок сервиса — где автоматизация помогает сопровождению, а где сначала надо стабилизировать требования и процесс.

flowchart LR
    A[SJM / BPMN / требования] --> B[Тест-анализ]
    B --> C[Критерии приёмки]
    C --> D[Чек-листы и тест-кейсы]
    D --> E[Выполнение и evidence]
    E --> F[Дефекты]
    F --> G[RCA и change request]
    G --> A

Что взять в работу

Software testing — тестирование даёт информацию о качестве и рисках, а не абсолютную гарантию отсутствия дефектов.
Test oracle — для каждого шага SJM нужен источник ожидаемого результата: требование, бизнес-правило, SLA, база знаний, регламент, system of record, лог или согласованный пример.
Risk-based testing — глубина проверки должна зависеть от customer harm, финансового/операционного/регуляторного impact, вероятности и восстанавливаемости.
Static testing — до разработки проверять SJM, BPMN, требования, шаблоны ответов, KB-статьи и SLA-правила.
Equivalence partitioning и Boundary value analysis — использовать для правил, сумм, сроков, лимитов, сегментов клиентов, категорий обращений и статусов.
Regression testing — держать компактный набор проверок для критичных статусов, интеграций, SLA-таймеров, уведомлений, маршрутизации и reopen-сценариев.
Defect — дефект сервиса фиксировать как расхождение между ожидаемым и фактическим поведением всей цепочки, а не только как баг приложения.

Матрица тестового охвата сервиса

Плоскость покрытия	Что проверять	Пример evidence
Клиентский путь	happy path, отказ, повторная попытка, непонятный статус	UAT, запись сессии, обращение
Процесс	роли, handoff, очередь, ручной обход, SLA	BPMN, workflow log, SLA report
Данные	system of record, синхронизация, видимость первой линии	CRM, справочник, trace
Интеграции	timeout, retry, duplicate protection, reconciliation	логи, контракт, synthetic check
Поддержка	категория, KB, шаблон ответа, escalation path	тикет, QA ответа, reopen
Recovery	fallback, компенсация, клиентская коммуникация	incident report, change request

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

Тестовая стратегия сервиса должна строиться от SJM: сначала определить критичные ожидания клиента и организации, затем для каждого ожидания указать oracle, риск, тестовый уровень, тип проверки, владельца дефекта и production-сигнал после запуска.

Как применять в сервисной модели

Превратить каждый критичный шаг SJM в проверяемое ожидание.
Для каждого этапа задать positive, negative и exception scenarios.
Проверить не только экран, но и backstage: маршрутизация, статусы, данные, SLA, уведомления.
Отдельно проверить поддержку: видит ли первая линия нужные данные, есть ли база знаний, корректно ли работает эскалация.
Для деградаций проверить fallback, retry, duplicate protection и service recovery.
Для найденных проблем писать service defect report: что произошло, где, при каких условиях, что ожидалось, как воспроизвести, какое evidence приложено.
После запуска связывать дефекты, повторные обращения и инциденты с RCA, change request и обновлением SJM.

Связь с SJM

SJM помогает строить тестовый охват:

Элемент SJM	Что тестировать
Customer action	может ли клиент выполнить действие и понять результат
Frontstage	сообщения, статусы, доступность, ошибки, уведомления
Backstage	маршрутизация, проверки, очереди, ручные действия
Systems	события, интеграции, source of truth, логи
Handoff	передача между командами и каналами
Exception	негативная ветка, recovery, повторная попытка
Metric	baseline, target, мониторинг после запуска

Связь с инструментами поддержки и сопровождения

Тестирование сервиса должно включать:

проверку категорий обращения;
проверку routing rules;
проверку базы знаний первой линии;
проверку SLA timers;
проверку шаблонов ответа;
проверку видимости статуса в CRM;
проверку reopen / повторного обращения;
проверку QA-контроля ответов поддержки;
проверку инцидентного сценария.

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

Ограничения

Нельзя доказать отсутствие всех дефектов.
Bug count сам по себе плохо показывает качество сервиса.
Тестирование без production evidence быстро устаревает.
Для Паттона и Вайнберга полный текст пока не предоставлен: source_required.