Стратегия приёмки системы «Обратная связь — регион»

Подход и формат сценариев

Сценарии конкретизируют требования системы «Обратная связь — регион» примерами. Правила и методическая основа: руководство, раздел «Подход к сценариям приёмки».

Например, SCN-POS-007 задаёт маршрут в два ведомства и согласованный ответ только одного из них. После создания поручений и попытки публикации проверяются принадлежность поручений одной жалобе, единственный ведущий ответственный и отказ публикации неполного ответа. Эталон случая CASE-POS-PARTIAL находится в наборе данных.

JSON-сценарии используют собственный профиль репозитория: их потребитель reqtool регулярно проверяет связи CHECK→REQ/aspect/CASE, эталоны и плановое покрытие. Они не исполняют проверки продукта. Для описаний без такого машинного потребителя используется Markdown; текущая автоматическая матрица их не учитывает. Данные, код проверки и результаты исполнения имеют разные назначения.

Приоритет рисков

Потеря жалобы, дубль регистрации, чужой доступ, неполный ответ, устаревший ответ после переназначения, неверный срок и аналитический двойной подсчёт — критические риски этого среза.

SCN-POS-001 — связный путь через несколько областей. Отказы и границы раскрываются другими сценариями. SCN-POS-003-01 связывает одно наблюдение с двумя REQ: дедупликация и аудит. SCN-POS-015 использует два временных среза; конкретные ожидаемые числа заданы в DATA-POS-ANALYTICS.

Применимость категорий

Успех:001,002,008. Ошибки входа:004. Альтернативы/уточнение:005,006. Полнота/многоведомственность:007,008. Повтор:003,008. Права:010,011,016. Версии/конкуренция:009,018. Недоступность/восстановление:013,014. Время/границы:015,017. Производительность:019.

Комбинации, не раскрытые в этом срезе, требуют отдельного планирования: истечение окна идемпотентности, ключи разных авторов, самостоятельное согласование исполнителем, поздние и повторные подтверждения провайдера, изменение справочника в процессе, запрещённая правка approved-ответа, несколько территорий, длительное уточнение. Текущее плановое покрытие не объявляется исчерпывающим доказательством качества.

Среда и данные

Изолированный стенд, синтетические пользователи/ведомства, управляемые часы, справочникv7, заглушка уведомлений и выделенный run_id. Общий стенд используется только с согласованным резервированием. Все данные задают начальный контекст и ожидаемый результат; schema validity не означает корректности бизнес-состояния.

Workflow-context.schema.json — контракт тестового контекста с разрешёнными дополнительными полями, а не промышленный API. Agency-response.schema.json — формат согласованного ответа ведомства; положительный и отрицательный эталоны нужно проверить при подключении адаптера.

Методы

Функциональные checks запланированы как test; конкретная реализация пока отсутствует (implementation=null). Нагрузочный сценарий — demonstration с протоколом. Проверка формул аналитики отдельным скриптом проверяет согласованность эталона и формулы; она не вызывает продукт и не является его приёмкой.

Готовность

--ready подтверждает заполненность формального плана приёмки системы «Обратная связь — регион». --release блокируется Q-POS-001..003, Q-ARCH-001 и Q-POS-005. Рабочий DEC-POS-007 разрешает реализацию политики повторов, сохраняя вопрос Q-POS-005 открытым. Перед приёмкой: закрыть блокирующие вопросы, реализовать проверки и сохранить результаты для проверяемой версии продукта.

Приёмка архитектурных обязательств

SCN-ARC-001 — будущий тест с реальной остановкой процесса на границе commit; SCN-ARC-002 — инспекция транзитивных зависимостей и SQL-grants. Их fixtures задают входы и оракулы, implementation=null. При реализации нужны исполняемые проверки и результаты на конкретной версии кода/среды; согласованность каталога их не заменяет.

SCN-ARC-003 — инспекция состава поставки по технологическому базису: разрешённые продукты, несогласованная замена и отсутствие фиксации сборки. Синтетический набор DATA-ARC-TECHNOLOGY задаёт эталоны инспекции; принятие реальной поставки требует инвентаризации сборки/среды, точных версий и результатов совместимости. Линтер проверяет связи и форму входа, но не сравнивает реально установленное ПО с базисом.