Приёмочное тестирование пользователем
UAT
Что это такое
Приёмочное тестирование пользователем — это подтверждение заказчиком или предполагаемым пользователем того, что построенное соответствует согласованной потребности. Проверку проводят те, кто просил о работе, и по каждому пункту выносится ясное «пройдено» или «не пройдено» — против согласованных требований.
Почему это важно
Это последнее дешёвое место, где можно поймать непонимание между спецификацией и тем, что имел в виду заказчик, — пока у команды ещё есть контекст, чтобы это исправить, и до того, как релиз сделает неверное поведение привычкой. Заодно происходит передача ответственности: подписанный инкремент принадлежит заказчику, а разговор о том, каким он должен был быть, идёт до поставки, а не после. Однако у этого места есть и режим отказа, о котором стоит сказать прямо: если критерии приёмки расплывчаты, UAT превращается во второй раунд сбора требований — их пишет заказчик по мере использования системы, за счёт времени команды и уже после того, как график взят на себя.
Ключевые идеи
Проверяйте против согласованных критериев, а не против настроения заказчика
Каждый пункт — проверка, которая либо проходит, либо нет, и запускать её нужно по подписанным требованиям, а не по свежему прочтению построенной системы.
REQ-PAY-014 возврат не должен превышать исходную сумму платежа
Проверка возврат €120 по платежу €100 -> отклонён, показана ошибка
Результат пройдено
REQ-PAY-020 статус возврата виден клиенту в течение 5 минут
Проверка вернуть, подождать, перезагрузить страницу заказа
Результат не пройдено -- статус появился через 22 минуты
Одна неоднозначная формулировка стоит здесь раунда переделки и разговора о графике.
Пишите сценарии до завершения сборки
Приёмочные сценарии выводятся из требований, поэтому могут существовать, пока код ещё пишется, — и, написанные рано, ловят пробелы в спецификации, пока команда ещё в работе.
Заказчик запускает, команда наблюдает
Шаги выполняет заказчик, а команда смотрит и записывает. Стоит сессии повести команда, и она неосознанно обойдёт шаги, которые проваливаются.
Отделяйте проваленные проверки от новых запросов
Самая частая ошибка UAT — расползание объёма, переодетое в дефект. Всё, что не трассируется к согласованному требованию, — это новый запрос со своим приоритетом, записанный и датированный, а не исправленный на месте.
Проваленная проверка статус не виден в течение 5 минут -> дефект, исправлять сейчас
Новый запрос «а может оно ещё и письмо клиенту посылать?» -> новый элемент, бэклог
Подпись — это запись, а не церемония
Назовите, что прошло, что нет и что отложено, с датой, — по этой записи и планируют следующую фазу.
Практика
Напишите приёмочные сценарии из требований
Возьмите пять согласованных требований и напишите сценарий проверки для каждого, включив как минимум один случай отказа из каждого.
Готово, когда: тот, кто не писал требования, может выполнить сценарии и прийти к вердикту, не обращаясь к автору.
Проведите одну приёмочную сессию и классифицируйте находки
Пусть заказчик выполнит сценарии, а вы запишите каждый исход как пройдено, не пройдено или новый запрос.
Готово, когда: каждая проваленная проверка называет требование, которое не прошло, и каждый новый запрос попал в бэклог с датой, а не был исправлен в ходе сессии.
Частые ошибки
- Расплывчатые критерии приёмки — UAT превращается в недисциплинированный сбор требований после сборки; исправить: проверяйте против критериев, согласованных до начала работы.
- Сессию ведёт команда — провальные шаги пропускаются; исправить: шаги выполняет заказчик.
- Новые запросы как дефекты — график впитывает объём, которого никто не согласовывал; исправить: классифицируйте их отдельно и отправляйте в бэклог.
- Сценарии, написанные после сборки — пробелы в спецификации обнаруживаются слишком поздно для дешёвого исправления; исправить: пишите их, пока код ещё пишется.
- Нет письменной подписи — никто не может сказать, что было принято или отложено; исправить: запишите, что прошло, что нет и что отложено, с датой.
Что читать дальше
- Инженерия требований (04-product-process/05-requirements-engineering) — прочитайте это первым; принимать нечего без согласованных и проверяемых требований.
- Ревью и трассировка требований (04-product-process/05-requirements-engineering/02-reviewing-and-tracing-requirements) — трассировка, которая привязывает каждую проверку к требованию.
- Юзабилити-тестирование (03-design-ux/33-usability-testing) — другая деятельность: наблюдают за реальными пользователями, которые пытаются выполнить задачи, а не подтверждают контракт.
- Работа со стейкхолдерами (04-product-process/07-stakeholder-management) — люди, чьё подтверждение фиксирует эта подпись.