В то время как пользовательские приемочные тесты (UAT) в теории кажутся чрезвычайно простыми, на практике зачастую все выходит иначе. В данной статье анализируется 5 типичных сложных ситуаций, возникающих во время проведения приемочных тестов, а также приводятся полезные советы специалистов для успешного их разрешения.
1. Обычно пользователям приходится освобождать время в их напряженном рабочем графике для того, чтобы участвовать в UAT-сессиях. Сколько времени реально необходимо пользователям для того, чтобы досконально протестировать систему?
Столкнувшись с острой нехваткой времени и подходящими сроками сдачи проекта, пользователи обычно в состоянии проверить работу лишь ограниченного числа последовательностей команд. Даже несмотря на то, что приемочные тесты ограничены лишь функциональными аспектами программного обеспечения, пользователям все равно может быть слишком мало отведенного времени, чтобы с достаточной степени изучить логику системы. Следовательно, результаты тестирования могут оказаться неполными и затронуть лишь поверхностные аспекты.
Рекомендация: Несмотря на то, что 100% полноценные приемочные тесты, покрывающие все аспекты – это миф (см. статью «7 Practical Software Testing Principles & Myths from Jerry Gao»), качество UAT можно существенно улучшить, начав приемочные тесты как можно раньше. Эти тесты должны проводиться в удобное для пользователей время, чтобы они никуда не торопились и имели достаточное количество времени на тестирование основных процессов в системе. Кроме того, может возникнуть необходимость проведения дополнительных сессий с целью убедиться, что результаты приемочных тестов достаточно информативны.
2. Обычно приемочные тесты проводятся уже после того, как известны результаты других тестов и система уже «практически» готова к запуску в эксплуатацию. Это часто случается уже тогда, когда система уже тестирована, и основное количество багов уже обнаружено и исправлено. Как правило, это происходит потому, что исполнители не хотят, чтобы у пользователей оставались негативные впечатления от работы с системой, либо потому, что исполнители не слишком уверены в своей способности разработать высококачественный программный продукт.
В такой ситуации приемочные тесты превращаются в обычную формальность и включают в себя лишь демонстрацию работы системы и учет некоторых замечаний по улучшению, и вовсе не фактическое тестирование системы, которое, собственно, предполагает UAT.
Большинство приемочных тестов начинаются с такой установки у заинтересованной стороны: «Мы хотим, чтобы пользователи протестировали нашу систему, но мы не хотим, чтобы они находили какие-нибудь серьезные баги, т.к. такие недоработки на этой стадии могут привести к задержке сдачи проекта». Такая позиция может привести к тому, что бизнес-аналитик или IT-отдел просто настоят на проведении повторного тестирования.
Рекомендация: Пользователи должны демонстрировать свою заинтересованность в системе / проекте путем создания собственных тест-кейсов. Эти тест-кейсы, вероятнее всего, будут основаны на сценариях, которые бизнес-аналитик может пропустить или же может вообще о них не знать. Тем не менее, на данном этапе бизнес-аналитик может заниматься: 1) пересмотром тестов с целью убедиться, что были учтены основные сценарии, 2) поддержкой настроек тестовых данных и среды, 3) поддержкой пользователей во время приемочного тестирования и 4) обеспечением документального подтверждения результатов теста.
3. В ситуациях, когда от пользователей не требуют создания их собственных тест-кейсов, важные сценарии могут быть упущены, что увеличивает риск возникновения проблем после развертывания приложения. В таком случае напрашивается вопрос: насколько ответственно пользователи подойдут к UAT, особенно учитывая тот факт, что у них есть основная занятость и множество других задач, не связанных с приемочным тестированием? Если за этими пользователями не стоит эффективное руководство, и у них отсутствует чувство причастности к работе над проектом, убедить пользователей в необходимости ответственного отношения и важности инвестирования своего времени может стать непростой задачей.
Рекомендация: Чтобы увеличить шансы на успех, руководство должно демонстрировать свою активную поддержку проекта, акцентируя важность приемочного тестирования и требуя обязательного тестирования и одобрения системы пользователями перед ее запуском в эксплуатацию.
4. В ситуациях, когда пользователи не имеют достаточного количества времени, чтобы исчерпывающе протестировать систему, довольно трудно получить одобрение системы. Это может вызвать перенос сроков сдачи проекта в случае, если одобрение является обязательным требованием перед запуском системы в эксплуатацию.
Рекомендация: Убедитесь, что пользователи в курсе работы над проектом и могут видеть прототипы системы, вовлеките их в процесс до стадии проведения приемочных тестов и одобрения системы – это повысит их чувство причастности к проекту и ответственности за него и предотвратит возможные задержки, вызванные недостаточной информированностью о системе.
5. Еще одна распространенная проблема UAT-сессий – это непонимание пользователями деталей работы системы. Вот почему в нашей команде мы начинаем демонстрацию системы и ее устройства, а также сами проводим несколько тестов до того, как просим пользователей создать свои собственные тест-кейсы. В нашем случае демонстрации, как правило, достаточно, потому что пользователи уже знакомы с BPMS платформой и поэтому тестируют только автоматизацию/логику новых процессов.
Рекомендация: Ознакомление пользователей с принципами работы системы играет важную роль для проведения эффективных приемочных тестов, однако эти мероприятия должны проводиться по отдельности, чтобы избежать превращения UAT-сессии в обучающий семинар. Пользователей необходимо обучить не только тому, как пользоваться приложением, но еще и помочь им найти верный подход, позволяющий тестировать систему эффективно.
С какими сложностями сталкиваетесь вы?
Автор: Stephanie Famuyide
Перевод подготовила Екатерина Зданевич
Оригинальная статья
P.S. Если вы недавно прочитали классную статью по бизнес-анализу и считаете, что ее стоит перевести, дайте нам знать, например, поделившись ссылкой в комментариях.
У автора оригинальной статьи явно неправильное представление о назначении UAT. В п. 2 сказано, что странно проводить UAT после полной проверки системы (QA). Однако целью UAT не является поиск багов в системе с привлечением конечных пользователей, а проверка соответствия реализации исходным ожиданиям/потребностям заказчика.
Согласен, что с помощью UAT мы валидируем требования, а не ищем баги. Касательно статьи: тут есть вероятность, что автор имела ввиду не поиск багов, а проверку на упущенные требования. Т.е. пользователи могут быстрее предоставить обратную связь касательно самого решения (бизнес-логики), не дожидаясь, пока будут устранены все дефекты.