UAT-тестирование: как принять продукт до запуска

Что такое UAT и чем он отличается от обычного тестирования?

Представьте, что вы заказали интернет-магазин. Программисты проверили каждую кнопку, и всё работает. Но вы садитесь оформлять заказ так, как это делает ваш отдел продаж, и оказывается, что промокод не принимает русские буквы и письмо покупателю не уходит. Код исправен, но магазином пользоваться нельзя. Такие вещи и ловит UAT.

Поэтому приёмку проводят не те, кто писал систему. Её проходят будущие пользователи и владельцы бизнес-процессов: они берут реальные задачи и смотрят, получается ли их решить. Технический сбой для них вторичен, главное, чтобы система помогала работать. Поэтому UAT идёт после всех технических проверок и перед выпуском. Тем же принципом проверки на людях пользуются A/B-тесты и исследования юзабилити.

Так определяет UAT и Яндекс Бизнес: это пользовательское приёмочное тестирование на финальной стадии перед запуском, которое смотрит на удобство и логику действий и оставляет технические ошибки предыдущим этапам. Результат влияет на решение о запуске: команда либо подтверждает готовность, либо возвращает продукт в доработку.

В международном стандарте та же мысль звучит формально. Глоссарий ISTQB, который цитирует Википедия, описывает приёмочное тестирование как проверку соответствия потребностям пользователей, требованиям и бизнес-процессам. Слово «приёмка» здесь точное: заказчик решает, принимает он работу или нет.

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

Когда продукт готов к приёмке?

Приёмку не начинают «по ощущениям». Команда CleverData перечисляет условия входа: бизнес-требования утверждены, код заморожен, модульное, интеграционное и системное тестирование завершены, критические ошибки устранены. Если проект ещё сырой, пользователи потратят время на баги, которые должны были найти тестировщики, и вместо оценки удобства получится второй этап отладки. Раздражённые участники потом неохотно возвращаются к проверке, даже когда продукт доведён до ума.

Стабильность проверяют и по другому признаку. По описанию Яндекс Бизнеса, система уже работает без критических ошибок, которые блокируют пользовательские сценарии, и доступна целиком, без заглушек вместо разделов. Тестовую среду при этом наполняют обезличенными данными, чтобы настоящие данные клиентов не попали в чужие руки.

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

Хорошо видно, что такое настоящая подготовка, на примере Университета Глазго. Перед запуском новой CRM для работы с абитуриентами университет собрал для приёмки более 50 сотрудников из британских и международных подразделений. За первые две недели они прошли более 1200 тестовых сценариев. В университете подчёркивают, что техническими сбоями здесь не занимаются, поиск их уже завершён. Сценарии шли по порядку: захват лидов, обращения, события, маркетинговые коммуникации, прогрев. Находки обсуждали с проектной командой и расставляли по приоритетам.

Виды приёмки: от альфы до чёрного ящика

Видов несколько, и в одном проекте они часто сочетаются. Альфа проходит внутри команды разработки, бета отдаёт продукт реальным внешним пользователям. UAT в узком смысле, по схеме CleverData, выполняет приглашённая группа сотрудников или лояльных клиентов по строгим сценариям. Бета выглядит свободнее: человек просто пользуется продуктом.

Остальные виды отличаются предметом проверки. Для удобства сведём их в таблицу.

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

Компании подбирают участников бета-теста по-разному. Манго Офис пишет, что разработчики игр делают рассылки через тематические ресурсы, каналы в мессенджерах и сообщества в соцсетях, чтобы собрать группу желающих. Для продуктов с большой аудиторией бета может длиться очень долго: Gmail был объявлен как ограниченная бета-версия, а вышел из беты спустя несколько лет. К публичному анонсу им уже пользовалась большая часть сотрудников Google.

Приёмка не всегда предсказывает судьбу функции. По рассказу Манго Офис, во ВКонтакте когда-то был рейтинг пользователей, но он не пользовался спросом, и его убрали. Автор признаёт, что на этапе UAT предвидеть такое удаётся не всегда. Поэтому приёмка снижает риск, но не отменяет аналитику после запуска. Для железа она выглядит иначе. Часы Apple Watch Ultra позиционируют как модель для спортсменов, и в Манго Офис объясняют, что UAT для них означает полевые проверки противоударных и антикоррозийных свойств. Там проверяют, выдержит ли вещь условия, ради которых её купили.

Как провести приёмку по шагам?

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

1. Запишите критерии приёмки до начала теста: что именно считается «готово».
2. Соберите сценарии на языке пользователя: «оформить заказ с оплатой картой», а не «отправить POST-запрос».
3. Подготовьте тестовую среду с безопасными данными и дайте участникам инструкции.
4. Назначьте тех, кто принимает решение, и тех, кто исправляет и подтверждает исправление.
5. Фиксируйте каждое расхождение с приоритетом, исправляйте и повторяйте проверку.
6. Подпишите решение: принять, принять с оговорками или вернуть на доработку.

Критерии нужны в первую очередь. Консультанты GSE объясняют это так: без критериев приёмки тестирование быстро превращается в спор. Один говорит «работает, нажал кнопку, статус сменился», другой «не работает, статус не тот и не в тот момент». В их примере менеджер в CRM должен видеть этап Approval только после того, как приложено коммерческое предложение и проверен кредитный лимит. Не записанное правило каждый понимает по-своему.

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

Роли лучше распределить заранее. По описанию CleverData, в процессе участвуют четыре стороны:

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

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

Вести сценарии можно в обычной таблице: номер, действие, ожидаемый результат, фактический результат, статус, комментарий. Дефекты удобнее собирать в баг-трекере, чтобы каждое расхождение имело владельца и срок. Когда трекера нет, подойдёт общий документ, но с одним правилом: у каждой строки есть ответственный.

Решение принимает бизнес, исполнитель его только готовит. Авторы GSE предупреждают: команда внедрения создаёт условия, объясняет настройки и чинит дефекты, но не сдаёт экзамен за заказчика. Если сценарий прошёл только потому, что аналитик подсказал обходной путь, значит, интерфейс или процесс нужно улучшать.

Как UAT выглядит в маркетинге?

Маркетологи сталкиваются с приёмкой при внедрении платформ и настроек. CleverData приводит три типовых сценария. Первый касается CDP: тест-кейс симулирует переход на сайт с разных устройств, авторизацию и звонок в колл-центр, а ожидаемый результат в том, что система склеивает разрозненные идентификаторы в единый профиль клиента.

Второй сценарий связан с рассылками. Для цепочки «Брошенная корзина» проверяют тайминги: клиент положил товар в корзину, через час срабатывает Web Push, а если его не прочитали, уходит SMS. Приёмка должна показать, что система строго держится каскадной логики и не шлёт всё сразу.

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

Идею легко перенести на небольшой сайт. Перед запуском новой формы заявки или счётчика пусть пройдёт путь клиента сотрудник, который не участвовал в разработке: отправит заявку, проверит, дошло ли письмо, появилась ли цель в Метрике. Для этого не нужен специальный инструмент, достаточно таблицы со сценариями и колонкой «результат». Через неделю после запуска пройдите путь клиента ещё раз: счётчики и формы иногда ломаются уже после правок на боевом сайте.

Что бывает, когда приёмку пропускают?

Хрестоматийная иллюстрация относится к американскому сайту медицинского страхования. По данным Википедии, за день до запуска HealthCare.gov стресс-тест подрядчиков показал, что сайт становится слишком медленным уже при 1100 одновременных пользователях, а ожидали 50-60 тысяч. В первую неделю, по некоторым оценкам, записаться смог лишь 1% желающих. Предупреждения звучали и раньше, и один из руководителей проекта, Гэри Коэн, говорил:

Все понимают, что первый день не будет идеальным

Гэри Коэн, чиновник CMS, об открытии сайта HealthCare.gov

Дорогой урок преподал и лондонский аэропорт. Перед открытием Терминала 5 организаторы набрали более 15 тысяч добровольцев для 68 пробных прогонов, но в день открытия British Airways отменила 34 рейса и приостановила регистрацию багажа. За следующие десять дней около 42 тысяч сумок не улетели с владельцами, и было отменено более 500 рейсов. Причиной назвали проблемы ИТ-систем и парковки.

Бывает и обратное: приёмка настолько серьёзна, что от неё зависит жизнь проекта. Инженер, который описывает свой первый проект в блоге BetaTesting, вспоминает, как команда делала Windows-приложение для калибровки двигателей грузовиков вместо старой текстовой программы. Если бы приёмка показала слабый результат, проект собирались убрать на «полку», как в финале фильма про Индиану Джонса. Бюджет на команду, которая упакует материалы, заложили заранее. Менеджер оценил шансы как «50 на 50».

Две истории показывают две стороны одного правила. Репетиция без нужных условий успокаивает, но запуск не страхует. Заранее объявленный критерий «пускаем или закрываем» дисциплинирует всю команду.

Где чаще всего ошибаются?

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

Дальше идут ошибки подготовки. Яндекс Бизнес напоминает, что при техническом языке сценариев пользователям сложно понять, что именно проверять, и качество теста падает. Вот что ещё стоит проверить в плане:

• кроме счастливого пути, в сценариях есть неверные данные, обрывы связи и массовые отписки от рассылок;
• у каждого сценария есть ожидаемый результат, записанный до начала теста;
• участникам выделено рабочее время вне «встреч между делом»;
• для исправлений и повторного прогона в плане оставлены отдельные дни;
• тестовые данные похожи на настоящие, без Lorem Ipsum и заглушек.

Четвёртая: участники относятся к приёмке как к лишней нагрузке. По материалу Яндекс Бизнеса такое формальное участие делает обратную связь поверхностной. Пятая связана с тестовым наполнением: интерфейс с Lorem Ipsum и заглушками снижает достоверность результатов, поэтому нужны реальные макеты данных. Шестая лежит на стороне заказчика: человек, привыкший к старой системе, оценивает новую через призму прежних процессов и часто принимает удобное за непривычное.

Есть и менеджерская ошибка. Если клиент видел систему только частями на демо после спринтов, он не заметит проблем сквозного процесса. Автор материала на DOU пишет, что именно на UAT заказчик оценивает систему в целом и в разрезе своих бизнес-процессов, без разбивки на отдельные функции.

Частые вопросы