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

UAT

Что это такое

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

Почему это важно

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

Ключевые идеи

Проверяйте против согласованных критериев, а не против настроения заказчика

Каждый пункт — проверка, которая либо проходит, либо нет, и запускать её нужно по подписанным требованиям, а не по свежему прочтению построенной системы.

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

Одна неоднозначная формулировка стоит здесь раунда переделки и разговора о графике.

Пишите сценарии до завершения сборки

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

Заказчик запускает, команда наблюдает

Шаги выполняет заказчик, а команда смотрит и записывает. Стоит сессии повести команда, и она неосознанно обойдёт шаги, которые проваливаются.

Отделяйте проваленные проверки от новых запросов

Самая частая ошибка UAT — расползание объёма, переодетое в дефект. Всё, что не трассируется к согласованному требованию, — это новый запрос со своим приоритетом, записанный и датированный, а не исправленный на месте.

Проваленная проверка  статус не виден в течение 5 минут  -> дефект, исправлять сейчас
Новый запрос          «а может оно ещё и письмо клиенту посылать?»  -> новый элемент, бэклог

Подпись — это запись, а не церемония

Назовите, что прошло, что нет и что отложено, с датой, — по этой записи и планируют следующую фазу.

Практика

Напишите приёмочные сценарии из требований

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

Готово, когда: тот, кто не писал требования, может выполнить сценарии и прийти к вердикту, не обращаясь к автору.

Проведите одну приёмочную сессию и классифицируйте находки

Пусть заказчик выполнит сценарии, а вы запишите каждый исход как пройдено, не пройдено или новый запрос.

Готово, когда: каждая проваленная проверка называет требование, которое не прошло, и каждый новый запрос попал в бэклог с датой, а не был исправлен в ходе сессии.

Частые ошибки

  • Расплывчатые критерии приёмки — UAT превращается в недисциплинированный сбор требований после сборки; исправить: проверяйте против критериев, согласованных до начала работы.
  • Сессию ведёт команда — провальные шаги пропускаются; исправить: шаги выполняет заказчик.
  • Новые запросы как дефекты — график впитывает объём, которого никто не согласовывал; исправить: классифицируйте их отдельно и отправляйте в бэклог.
  • Сценарии, написанные после сборки — пробелы в спецификации обнаруживаются слишком поздно для дешёвого исправления; исправить: пишите их, пока код ещё пишется.
  • Нет письменной подписи — никто не может сказать, что было принято или отложено; исправить: запишите, что прошло, что нет и что отложено, с датой.

Что читать дальше