Приёмочное тестирование пользователем — Примеры

Пример 1 — Таблица UAT, смешивающая дефекты и пожелания

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

Заметки сессии
  возврат прошёл нормально
  статус показывался долго, минут 20+
  а может оно ещё и письмо клиенту посылать?
  возврат на подарочную карту заблокировался, хорошо
  было бы приятнее, если бы кнопки были зелёные

Решение

REQ-PAY-014  возврат не должен превышать исходную сумму платежа
  Проверка   вернуть платёж с подарочной карты -> отклонён, показана ошибка
  Результат  пройдено
REQ-PAY-020  статус возврата виден клиенту в течение 5 минут
  Проверка   вернуть, подождать, перезагрузить страницу заказа
  Результат  не пройдено - статус появился через 22 минуты
Новый запрос  письмо клиенту при возврате -> элемент бэклога, с датой
Новый запрос  зелёные кнопки -> отклонён как вне объёма, с датой

Проверка против согласованных критериев, а не против настроения заказчика, превращает «показывался долго» в конкретный отказ с номером требования — именно с ним команда может работать и его может трассировать. Классификация идеи с письмом как нового запроса удерживает её вне счёта дефектов и вне графика, где иначе спряталась бы самая частая ошибка UAT — расползание объёма, переодетое в дефект. Однако ловушка подстерегает рядом: если исправить новый запрос на месте, у него не останется ни приоритета, ни согласованного владельца.

Пример 2 — Подпись, о которой ничего не записано

Команда провела сессию, закрыла тикеты и сказала заказчику, что всё принято, — но происшедшее нигде не записано. Ниже заметки; составьте письменную подпись и скажите, когда следовало написать сценарии.

Сессия
  5 требований прогнаны, шаги выполнял заказчик
  4 пройдено; 1 не пройдено (статус слишком медленный); 2 новые идеи
  команда сказала «выглядит хорошо, развернём»

Решение

Подпись  дата 2026-08-14
  Пройдено    REQ-PAY-014, REQ-PAY-017, REQ-PAY-019, REQ-PAY-021
  Не пройдено REQ-PAY-020 (статус через 22 минуты) - исправить и перепроверить
  Отложено    нет
  Новое       письмо при возврате; зелёные кнопки - оба в бэклоге, с датой

Подпись — запись, по которой планируют следующую фазу: в ней названо, что прошло, что нет и что отложено, с датой, так что помнить сессию никому не нужно. Сценарии за ней должны были появиться до завершения сборки: выведенные из требований, они ловят пробел в спецификации, пока код ещё пишется, а не после того, как график взят на себя. Ловушка — заказчик так и не выполнил шаги: если сессию ведёт команда, провальные шаги пропускаются неосознанно.