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

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

Что такое УАТ?

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

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

UAT против тестирования качества

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

Кто управляет UAT?

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

Виды УАТ

Семиэтапный процесс UAT

1. Определите объем и цели

Решите, что принимается, что выходит за рамки и какие результаты бизнеса имеют значение. Например: «Финансовый персонал может подать, утвердить и оплатить требование о расходах в любой поддерживаемой валюте».

2. Согласуйте критерии приемки

Запишите простым языком, как выглядит успех, в идеале — в начале проекта, а не за неделю до запуска. Расплывчатые критерии позже приводят к спорам.

3. Выберите и проинструктируйте тестировщиков

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

4. Подготовьте среду и данные

Среда UAT должна быть максимально приближена к производству. Используйте реалистичные данные, настройте правильные роли пользователей и проверьте интеграцию, например электронную почту. Если вы копируете производственные данные, сначала замаскируйте личную информацию. Запустите быстрый дымовой тест, чтобы тестировщики не пришли и не обнаружили сломанную сборку.

5. Пишите сценарии

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

6. Запустите тесты и соберите отзывы

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

7. Исправьте, повторно протестируйте и подпишитесь.

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

Тестовый пример UAT

Тестовый пример UAT должен быть простым для понимания человеком, не имеющим технических знаний. Вот пример системы расходов:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Обратите внимание, что здесь описана реальная задача, а не технические подробности, и оставляет место для комментариев. Эти комментарии часто оказываются самой ценной частью, например: «Это работает, но я никогда не найду эту кнопку».

Критерии входа и выхода

Они вписываются в более широкий жизненный цикл тестирования программного обеспечения. Заранее установите цифры вместе с заинтересованными сторонами. Фраза «Мы решим, когда будет удобно» обычно приводит к поспешному «да», обусловленному дедлайном.

Обработка отзывов

Обратная связь UAT — это смесь вещей, и не все из них являются ошибками. Рассортируйте его по категориям:

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

Контрольный список UAT

До УАТ

• Объем и критерии приемки согласовываются в письменной форме.
• Завершено системное и регрессионное тестирование.
• Тестировщиков выбирают, инструктируют и дают время
• Среда, счета и реалистичные данные готовы
• Персональные данные в копиях замаскированы
• Сценарии рассматриваются бизнесом
• Создано единое место для записи проблем.
• Имя владельца подписи

Во время UAT

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

После UAT

• Критерии выхода проверены
• Известные проблемы задокументированы вместе с владельцами.
• Официальное подписание записывается
• Примечания к обучению и выпуску обновлены.
• Состоялась небольшая ретроспектива

UAT в Agile-командах

Традиционный UAT представляет собой один большой завершающий этап, где сюрприз обходится дорого. Agile-команды сокращают этот цикл. Владельцы продукта проверяют каждую историю на соответствие ее критериям приемлемости во время спринта, а пользователи видят работающее программное обеспечение на обзорах спринта. Многие команды по-прежнему запускают специальный UAT перед выпуском основного релиза, особенно когда несколько функций объединяются в один рабочий процесс.

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

Распространенные ошибки

• Относиться к этому как к формальности. Подписание договора без реальной пользы никого не защищает.
• Использование неправильных тестировщиков. Разработчики и специалисты по контролю качества слишком хорошо знают систему, чтобы представлять пользователей.
• Начинаем с нестабильной сборки. Тестировщики быстро теряют доверие и интерес.
• Оставляя это на последнюю минуту. Тогда не будет времени исправлять то, что вы узнали.
• Использование нереалистичных данных. Тестовые данные редко бывают такими запутанными, как в реальной работе.
• Давайте расширять возможности. Относитесь к новым идеям как к запросам на изменения, если только они не являются настоящими блокировщиками.

Итоги

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

Часто задаваемые вопросы

Продолжайте учиться