Модуль 6.3. Приемочные испытания и UAT
Темы: план UAT, роли, дефекты, вход/выход, sign-off. Артефакты: план UAT + чек-лист. Практика: смоделировать UAT-сессию.
UAT (User Acceptance Testing) — финальный фильтр перед релизом: бизнес подтверждает, что система делает то, что обещано и так, как это нужно пользователю. Задача системного аналитика — подготовить план, обеспечить готовность среды и данных, связать UAT со Scenario/BDD/AC, управлять дефектами и довести процесс до sign-off.
В конце модуля у вас будут:
- готовые шаблоны плана UAT, чек-листы входа/выхода, формы sign-off;
- дефиниции severity/priority, SLA на исправления, регламенты triage и дефект-комитетов;
- методика моделирования UAT-сессии на живом кейсе (платёж/возврат/пагинация).
Что такое UAT (и чем он не является)
- Цель UAT: подтвердить, что релиз решает бизнес-задачу в условиях, близких к реальным (роли, данные, процессы, интеграции), и критерии приёмки (AC) выполняются.
- Не цель UAT: находить массово технические дефекты низкого уровня; этим занимались модульные тесты, интеграция и SIT.
- Артефакты входа: фича-файлы (Gherkin), AC, RTM, спецификации API/событий, миграции БД, NFR-каталог, observability-spec, политика данных и доступов.
- Артефакты выхода: протоколы UAT, реестр дефектов с решениями (fixed/deferred/won’t fix), решение о релизе (sign-off/go-no-go).
Роли и ответственности (RACI)
|
Роль |
Ответственность |
|---|---|
|
Бизнес-спонсор / Владелец продукта (PO) |
Утверждает цели UAT, принимает решение о релизе (sign-off) |
|
UAT-лид (обычно SA) |
План/организация, вход/выход, синхронизация с QA/Dev/DevOps, брифинг пользователей |
|
Представители бизнеса/Суперпользователи |
Выполняют сценарии, дают доменную обратную связь |
|
QA/Тест-менеджер |
Методика, учёт кейсов/результатов, контроль дефектов |
|
Разработчики |
Быстрые исправления, разъяснения, участие в разборе дефектов |
|
DevOps/SRE |
Среда UAT, фичефлаги, развертывания, доступы, наблюдаемость |
|
DWH/BI, Безопасность/Юристы (по контексту) |
Проверяют отчёты/правила/комплаенс, подписывают секции плана |
RACI (фрагмент):
- Подготовка среды: R(DevOps) A(SRE) C(SA) I(PO)
- Утверждение сценариев: R(SA) A(PO) C(QA) I(Dev)
- Sign-off: R(PO) A(PO) C(SA, QA, SRE) I(Dev)
Жизненный цикл UAT
- Планирование: цели/объём, критерии входа/выхода, расписание, роли, риски.
- Подготовка: среда (pre-prod), данные (seed/обезличка), доступы/роли, фичефлаги, брифинг и обучение пользователей.
- Исполнение: циклы (Wave 1/2), ежедневные стендапы, оперативные патчи, фиксация evidence (скриншоты/видео/логи/ID трасс).
- Дефекты: логирование → triage → фиксы → ретест → отчёт.
- Аналитическая приёмка NFR: смоки p95/ошибки/лаг очередей по ключевым SLI.
- Выход/Sign-off: выполнение критериев → протокол UAT → решение go/no-go → подготовка релизной заметки.
Критерии входа/выхода (Entry/Exit)
Entry (в UAT можно):
- Развёрнут Release Candidate (build + номер), миграции БД применены, фичефлаги — в нужном состоянии.
- SIT/Регресс пройден(ы), блокеров Severity 1 нет, по Severity 2 — только согласованные «deferred» с workaround.
- Подготовлены данные (обезличенные/синтетические), роли/доступы выданы.
- Актуальны AC/BDD, RTM и чек-листы, готовы формы дефектов.
- Включена наблюдаемость: трассировки, логи, дашборды SLI.
Exit (UAT принято):
- Выполнено ≥ 95% критичных сценариев; оставшиеся — документированы.
- Нет открытых S1; S2 — не более N с согласованным deferral и описанными рисками/планом.
- Пройдены контрольные NFR (latency/error-rate/lag) в бизнес-окно.
- Подписан протокол UAT (PO + UAT-лид + QA + SRE).
- Обновлены пользовательские инструкции/обучающие материалы.
Дефекты: классификация, SLA, поток
Severity (тяжесть) и Priority (срочность)
|
Severity |
Описание |
SLA фикса (на UAT) |
|---|---|---|
|
S1 — Blocker |
Критичная функция недоступна/потеря данных/необратимые последствия |
Фикс сразу, релиз стоп |
|
S2 — Major |
Существенная деградация без обхода |
Фикс в 24–48 ч или deferral с рисками |
|
S3 — Minor |
Некритичные ошибки/UX/локализация |
По плану |
|
S4 — Trivial |
Косметика/текст |
По бэклогу |
Priority: P0 (немедленно), P1 (в следующем патче), P2 (после UAT), P3 (бэклог).
Жизненный цикл тикета (Jira/YouTrack)
New → Triage → Open → In Progress → Fixed → In Review (UAT Retest) → Closed / Reopened → Deferred (если согласовано)
Triage (ежедневно): SA+QA+PO+Lead Dev. Решаем: severity/priority, владелец, план.
Шаблон описания дефекта
Заголовок: [UAT] Refund: сумма > captured не блокируется (ошибка правила) Окружение: UAT env v1.12.3 (build #456), tenant=A, feature flags: refunds.enabled=true Шаги: 1) POST /refunds amount=200 при captured=150; 2) ... Ожидаемо: 422 REFUND_EXCEEDS_CAPTURED, аудит отказа Фактически: 201 Created Доказательства: видео, скрин, trace_id=4f2a..., логи (attach), SQL before/after Влияние: S2 Major (возможен неверный учет) Workaround: нет Связи: AC-Refund-2, RTM-57, Spec v2.1 §3.4
План UAT — шаблон (скопируйте в Confluence)
# UAT Plan — <Проект/Релиз> vX.Y.Z ## 1. Цели и область - Цели: подтвердить <бизнес-результат>, проверить AC/NFR, обучить ключевых пользователей - В Scope: <модули/процессы>; Out of Scope: <…> ## 2. Сценарии и источники правды - Перечень сценариев: ссылка на .feature/AC/RTM - Оракулы: API/БД/события/аудит/дашборды SLI ## 3. Среда и конфигурации - Env: UAT/pre-prod URL, build#, миграции - Фичефлаги: таблица флагов и целевые состояния - Доступы/Роли: кто к чему - Данные: источник, метод (обезличка/синтетика), объёмы, правила очистки ## 4. Расписание - Окно UAT: <даты/часы> (Europe/Stockholm) - Циклы: Wave 1 (функционал), Wave 2 (NFR/регресс) - Дейлик: 15 мин, triage: ежедневно 30 мин ## 5. Роли и контакты - PO, UAT-Lead(SA), QA, Dev Lead, SRE, Data, Security — Slack/телефоны ## 6. Критерии входа/выхода - Entry: список чек-пунктов - Exit: pass-rate, дефекты (S1=0, S2≤N), NFR, sign-off ## 7. Дефекты и отчётность - Severity/Priority/SLA - Доска UAT, отчёты (бурндаун дефектов, pass-rate) - Политика deferral и процесс согласования ## 8. Риски и меры - Таблица рисков (ID, риск, вероятность/влияние, владелец, план) ## 9. Безопасность и комплаенс - Классы данных на UAT, маскирование, политика доступа к логам, срок хранения артефактов ## 10. Приложения - Чек-листы (Entry/Exit), протокол UAT-сессий, шаблон sign-off
Чек-листы (готовые)
Entry Check (короткий)
- RC развёрнут, миграции прошли, флаги включены
- Фичи/AC/RTM актуальны и доступны участникам
- Данные загружены, роли заведены (MFA/доступы)
- Дашборды/трейсы доступны; алерты включены
- Каналы связи/календарь встреч созданы
Daily Run
- Вчерашние блокеры закрыты/в работе
- Новые дефекты протриажены
- План патча/кат-фикса согласован
- Обновлены прогресс-метрики (pass-rate, дефекты по severity)
Exit Check
- S1=0; S2 — в рамках политики deferral
- Pass-rate ≥ целевого (например, 95% критичных сценариев)
- Наблюдаемость OK: p95/p99/ошибки — в SLO-окне
- Обновлены инструкции/обучалки/релиз-ноты
- Подписан протокол UAT и форма sign-off
Пример — UAT кейс «Платёж и Возврат» (фрагменты)
Сценарии UAT (от бизнеса):
- «Оплата заказа картой RUB минимальной суммы» — подтверждение чека/уведомление/статус «PAID».
- «Частичный возврат 50%» — проверка отчёта и уведомления клиенту, отсутствие PII в событиях.
- «Недоступен PSP» — 202 Accepted + отложенная обработка ≤ 5 минут.
- «Пагинация заказов без дублей» — последовательные страницы.
Наблюдаемость: бизнес-дашборд «доля успешных оплат» и тех-дашборды p95/ошибки.
Данные: 20 тестовых клиентов/заказов/валют; seed-скрипты, фикса времени (UTC) для воспроизводимости.
Эвиденс: скрин чека, paymentId, trace_id, запись в «аудит», SQL-сверка.
Политика deferral (что можно «увезти вправо»)
- Допустимо: Minor/Trivial, не нарушающие AC и безопасность, без влияния на отчётность/юридические обязательства.
-
Нельзя: Любые S1; S2, влияющие на деньги/данные/комплаенс; нарушения NFR по SLA клиентов.
Каждый deferral — карточка «Риск» в релиз-заметке с владельцем и сроком исправления.
Sign-off: протокол и форма (шаблоны)
Протокол UAT-сессии (минуты):
Дата/время: 2025-08-20 15:00–16:00 (Europe/Stockholm) Присутствовали: PO, SA, QA, SRE, Dev Повестка: статус сценарием, дефекты, NFR, решение по релизу Результат: Pass-rate 97%, S1=0, S2=1 (Deferred: RISK-12, workaround ok) Решение: GO / (NO-GO причины …) Действия: Dev фикc #789 до T+3 дня, SA — обновить инструкции Подписи: …
Форма Sign-off (1 страница):
# Acceptance Sign-off — Release vX.Y.Z Дата: <…> Подписанты: PO (ФИО), UAT-Lead/SA (ФИО), QA Lead, SRE Lead Итоги UAT: - Сценарии критичные: <N>, пройдено: <Npass> (Pass-rate <…>) - Дефекты: S1=0; S2=<…> (Deferral ID:…, риск/план) - NFR: p95/p99/ошибка в окне <…> — соответствует/не соответствует Решение: [GO] / [NO-GO] Условия (если есть): <…> Подписи: <…>
Риски UAT и их гашение
|
Риск |
Проявление |
Меры |
|---|---|---|
|
Нет времени у бизнеса |
Срывы сроков |
Раннее планирование, короткие сессии, «bug bash» слоты, демо-видео |
|
Нет данных/доступов |
Стоп процессов |
За 3–5 дней до старта — dry-run готовности (Entry Check) |
|
UAT превращается в SIT |
Много мелких тех-багов |
Жёсткий Entry, предварительный регресс/SIT, «врезка» релиза |
|
Споры о «кто прав» |
Эмоции вместо фактов |
AC/BDD как источник правды + запись evidence |
|
Не поймали NFR-дефекты |
Падение в проде |
Мини-SLO-смоки на UAT, наблюдаемость/дашборды |
|
«Незаметные» изменения конфигов/флагов |
Не-воспроизводимость |
Протокол конфигов/флагов (hash), хранить в Git/Confluence |
|
Scope creep |
Бесконечный UAT |
Заморозка скоупа, change control на добавления |
Практика: смоделировать UAT-сессию (90–120 мин)
Вход: кейс «Создание платежа / Частичный возврат / Пагинация».
Шаги:
- Заполните UAT Plan (шаблон выше) под ваш релиз, определите Entry/Exit.
- Сформируйте список из 8–12 UAT-сценариев (можно взять из .feature 6.2).
- Подготовьте данные/роли/фичефлаги; сделайте Entry Check (галочки).
- Проведите «сессию 60 минут»: раздайте сценарии, собирайте evidence (скрины/trace_id/SQL).
- Заведите 3 дефекта (S1/S2/S3) по шаблону, проведите triage.
- Выполните Exit Check и заполните Sign-off (GO/NO-GO).
- Сформируйте итоговую заметку (ссылки: план, чек-листы, дефекты, evidence, решение).
Критерии зачёта:
- План и чек-листы заполнены и консистентны.
- Есть полный набор evidence по ≥5 сценариям.
- Дефекты классифицированы корректно; протокол triage.
- Exit выполнен; форма sign-off оформлена.
Вопрос–Ответ
В: Чем UAT отличается от SIT/QA?
О: UAT проверяет полезность для бизнеса и соответствие AC в реалистичном сценарии. SIT — техническая интеграция. В UAT дефекты уровня «кнопка на пиксель» допустимо отложить.
В: Можно ли использовать прод-данные на UAT?
О: Только обезличенные/с согласия и по политике. Вариант — «срез» с токенизацией и масками.
В: Кто «подписывает» UAT?
О: Владельцы бизнеса/PO. SA/QA/SRE дают заключения, но решение — у бизнеса.
В: Что делать, если UAT «горит», а релизное окно завтра?
О: Честный NO-GO при S1/S2 без обхода. Альтернативы — понижение флагом/деградация, «canary» на долю трафика, перенос.
В: Как фиксировать «неявные» ожидания?
О: Переводить в AC/BDD. Любой спор → уточнение, апдейт спецификаций, версия.
В: Почему нужны evidence?
О: Чтобы спор решался фактами, а не словами; облегчает ретесты и расследования (trace_id, скрин, логи, SQL).
Шпаргалка (распечатайте)
- Entry строгий → UAT не превращается в SIT.
- AC/BDD/RTM — источник правды; evidence к каждому сценарию.
- Severity/priority и triage ежедневно; deferral — только с рисками и владельцем.
- NFR-смоки и наблюдаемость — обязательны.
- Sign-off — решение бизнеса, оформленное документально.
