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

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

Определите предмет проверки

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

Задайте вопрос, на который должен ответить этап. Например: «Могут ли оператор, диспетчер и мастер провести заказ от регистрации до передачи в смену без потери ответственного и обязательных данных?»

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

Руководство GOV.UK о наблюдаемом тестировании полезно для организации сессии: человеку дают реалистичную задачу и наблюдают действия. Формальное решение о приёмке дополнительно опирается на согласованные требования и полномочия заказчика.

Выбирайте участников по различиям работы

Составьте карту ролей и условий, а затем назначайте людей. Для системы заказов в неё могут войти:

Не всем нужно проходить все сценарии. Но каждое существенное право и передача ответственности должны иметь своего проверяющего.

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

Подготовьте сценарии заранее

Используйте критерии как наблюдаемые результаты, а задания формулируйте на языке работы. Вместо «откройте раздел, нажмите плюс и заполните поле» напишите: «Зарегистрируйте поступивший заказ и передайте его диспетчеру».

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

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

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

Заполненный пример плана UAT

Рассмотрим условное внедрение системы внутренних заказов.

Цель: проверить передачу заказа между оператором, диспетчером и мастером с сохранением данных и ответственности.

Среда: отдельный стенд, версия 0.9.4, искусственные клиенты и изделия. Производственные сообщения отключены или направляются в согласованные тестовые каналы.

Участники: два оператора из разных смен, диспетчер, мастер, владелец процесса и наблюдатель. Руководитель проекта организует работу, но не отвечает за всех пользователей.

Набор: десять сценариев — четыре обычных, четыре исключения и две проверки доступа. Такое количество выбрано для учебного примера.

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

Результат: реестр проверок, реестр замечаний, решение о запуске либо список условий следующей попытки.

Расписание учитывает участие сотрудников, а не только свободное время команды разработки. Например, три парные сессии по 90 минут — это 4,5 часа календарных встреч и 9 человеко-часов участников. Наблюдатель потратит ещё 4,5 часа; подготовка и разбор считаются отдельно.

Карточка конкретного задания

К задаче приложите образец ожидаемых данных. Если мастер называет остаток 12, а система показывает 10, должно быть понятно, какая исходная операция объясняет разницу.

Как учитывать замечания

Не складывайте в один список ошибки, пожелания и вопросы обучения. Для каждого обращения зафиксируйте тип, условия воспроизведения, ожидаемый результат, фактическое поведение и влияние.

Дефект нарушает согласованное правило. Новая потребность добавляет результат, которого не было в объёме. Проблема понятности мешает выполнить задачу без пояснения. Ошибка данных требует исправления набора либо преобразования. Блокировка среды не позволяет сделать вывод о функции.

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

Для исправления сохраните идентификаторы объектов, версию и воспроизводимые шаги. Не публикуйте в общем реестре лишние персональные данные или секреты доступа: искусственный пример обычно достаточен.

Кто принимает окончательное решение

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

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

Если допускается временное ограничение, запишите обходной порядок, ответственного, срок устранения и критерий окончания. Формулировка «запускаемся, потом разберёмся» не задаёт управляемых условий.

После исправления повторите затронутые сценарии с пользователями. Устное сообщение разработчика об исправлении не заменяет подтверждения рабочего результата.

Что подготовить на этой неделе

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

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

Проверьте готовность следующей смены

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

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

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

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

Источники

Все материалы →