User acceptance testing — это приемочное пользовательское тестирование. Его проводят конечные пользователи софта после того, как разработчики и профессиональные тестировщики проведут свои тесты. Цель приемочного тестирования — убедиться, что программа соответствует бизнес-требованиям.
Нередко это «финальный рубеж», последний этап разработки софта до того, как его будет оценивать и принимать заказчик.
Гораздо дешевле исправить продукт на ранних стадиях разработки на основе собранных реальных отзывов пользователей, что позволяет избежать серьезных финансовых потерь при запуске из-за неудобного функционала.
В этом материале мы расскажем, как и зачем проводится User acceptance testing и кто в нем участвует.
Чем не является UAT
Кто участвует в UAT
Как спланировать UAT
Как оценивать работу разработчиков
Как провести UAT
Чем не является UAT
Это не техническое тестирование: оно не направлено на поиск багов в коде, проверку производительности или проверку интеграций. Если же такие проблемы выявляются, то программу направляют на доработку и исправление ошибок, после чего планируется повторное тестирование.
Это далеко не первый тест: профессиональные тестировщики включаются в проект разработки софта еще на стадии дизайна.
“Тестирование на раннем этапе помогает компании сократить расходы на разработку и предусмотреть возможные баги. Следуя тесткейсам, разработчики сразу закладывают функционал, учитывающий все слабые места. На следующем этапе, когда продукт готов, его передают тестировщикам на функциональное и регрессионное тестирование. Первый вариант включает проверку системы на соответствие изначальным требованиям, а второй – тестирование всей программы после внедрения новых функций”, – объясняет Senior QA Engineer Инна Ионова.
Это не разовое явление: Согласно опросу компани Ogrisoft, более 75 процентов респондентов заявили, что проводят несколько циклов тестирования конечными пользователями, при этом 57 процентов в качестве причины назвали низкое качество продукта.
Это не повод переделывать программу: Функционал программы создается на этапах генерации гипотез и сбора требований. А на UAT команда валидирует имеющиеся гипотезы. Новые идеи и инсайты должны включаться в продуктовый бэклог, чтобы реализовать их уже на следующей итерации.
Это нельзя пропускать: Гораздо дешевле исправить продукт на ранних стадиях разработки на основе собранных реальных отзывов пользователей. Это позволит избежать серьезных финансовых потерь при запуске из-за плохого функционала и удобства использования.
Кто участвует в UAT
Самые главные участники UAT — конечные пользователи продукта. Они впервые получают “в руки” разработанную программу и предоставляют свою обратную связь. Обычно у команды разработчиков уже будет готовый список пользователей, собранный еще на этапе Customer development. Они представляют собой целевую аудиторию разрабатываемого продукта. Но если списка нет, то можно провести рекрутинг, создав лэндинговую страницу с описанием программы и требованиями к целевой аудитории. Эксперты рекомендуют набирать от 30 до 1 200 пользователей, называя оптимальным числом 100 человек.
Любовь с первой итерации: зачем нужны сторонники продукта
Стейкхолдеры. Это заинтересованные стороны, участвующие в проекте. В их числе могут быть и заказчики, и представители команды разработки и даже регуляторы — если софт разрабатывается для государства или требует соблюдения дополнительных нормативных требований. С их участием продуктовой командой разрабатываются планы и критерии для организации приемки.
Бизнес-аналитики помогают организовать процесс и объясняют пользователям, что проверять. Конечные пользователи проводят тесты и дают обратную связь. Тестировщики помогают в составлении тест-кейсов, а разработчики исправляют обнаруженные ошибки.
Как спланировать UAT
Успешное пользовательское тестирование от провального отличается прежде всего наличием согласованного с командой плана.
- Чтобы ответить на вопрос “Насколько софт соответствует бизнес-требованиям?” команде необходима качественно подготовленная документация. Некачественную документацию отличают пробелы в сборе требований и отсутствие ясности у заказчика.
Когда все идет не по плану — лайфхаки для эффективного сбора требований
Чтобы ответить на вопрос “Успешно ли софт прошел тесты?”, необходимо сформулировать критерии приемки. Критерии тестирования должны быть конкретными, измеримыми и соответствовать целям теста. Их формулируют еще до начала разработки.
Результатом планирования должен быть готовый документ, в котором бизнес-аналитик укажет, как минимум, участников, критерии, тестируемые функции и сценарии, по которым будет проводится тестирование.
Позвольте докопаться: что такое артефакты в сфере IT
Напомним, что такое требования. Это описание того, что должен выполнять продукт или система для решения задач бизнеса. Они помогают сформулировать ожидания и определить функциональные возможности, которые должна поддерживать разрабатываемая система.
Как оценивать работу разработчиков
Еще на этапе сбора требований продуктовая команда должна согласовать с ключевыми стейкхолдерами критерии приемки. Существует множество способов оценивать работоспособность программ, ключевым моментом является то, что договариваться с командой разработки об этом необходимо еще до того, как будет написана первая строчка кода.
Пример критериев приемки, основанных на правилах
User story: Как путешественник, я хочу искать по городу, названию или улице, чтобы иметь больше вариантов подходящих отелей.
Критерии приемки для интерфейса базового поиска:
- Поле поиска расположено в верхней панели
- Поиск начинается, как только пользователь нажимает кнопку «Поиск»
- Поле содержит заполнитель с текстом серого цвета: «Куда вы направляетесь?»
- Заполнитель исчезает, как только пользователь начинает вводить текст
- Поиск выполняется, если пользователь вводит город, название отеля, улицу или их комбинацию
- Поиск возможен на английском, французском, немецком и украинском языках
- Пользователь не может ввести более 200 символов
- Поиск не поддерживает специальные символы. Если пользователь ввел специальный символ, появляется предупреждающее сообщение: «Поле поиска не может содержать специальные символы.»
Возможно, на этапе сдачи работы заказчику, этот документ будет одним из самых главных для оценки результатов работы всей команды. Именно поэтому критерии приемки должны быть написаны простым и понятным для всех стейкхолдеров языком, без излишних технических деталей. Например: «Пользователь должен иметь возможность применять набор фильтров для поиска определенных элементов».
Лайфхаки для эффективного сбора требований: “Я имел в виду другое”
Как проводить UAT
Неслучайно составление рабочих документов для конечных пользователей происходит уже после набора кандидатов. Ведь для написания хороших тестовых сценариев и скриптов для приемочного тестирования (UAT) важно привлекать конечных пользователей к их одобрению, чтобы учесть все возможные варианты использования, как обычные, так и редкие. Также рекомендуется писать их на простом языке, избегая сложных формулировок и чрезмерно технических объяснений, советуют представители компании Alexsoft.
Тест-кейсы — это конкретные действия, которые выполняются для проверки определенного поведения, функции или функциональности системы. Они более детализированы и должны соответствовать всем тестовым сценариям. Обычно тест-кейсы составляются на основе пользовательских историй и бизнес-кейсов. Примеры тест-кейсов включают проверку добавления товара в корзину незарегистрированным пользователем или проверку кнопки «продолжить покупки».
Эффективность тест-кейсов достигается, если в них четко указана цель и пользователю понятно, что нужно сделать для выполнения. Включение ожидаемых результатов в тест-кейс помогает пользователю заранее понять, что должно произойти, что упрощает выполнение тестирования и подтверждает корректность работы системы. С шаблонами можно ознакомиться здесь.
Информацию для тестирования берут из составленных ранее документов бизнес-требований. Каждый шаг и результат пользовательского приемочного тестирования фиксируются, чтобы можно было оценить, насколько продукт соответствует требованиям. Важно записывать как успешные, так и проблемные шаги, чтобы разработчики могли учесть всю обратную связь.
Очень важно проводить онбординг набранных тестировщиков. Им необходимо предоставить понятные инструкции, информацию о том, как пользоваться программой и как и в какой форме направлять обратную связь.
Самый простой формат отчета включает в себя краткое описание ошибки, шагов для ее воспроизведения, ожидаемый результат (как должно быть?) и фактический результат (как есть сейчас?).
Если в процессе UAT выявляются ошибки, их необходимо зарегистрировать. Бизнес-аналитик помогает фиксировать дефекты и передавать их команде разработчиков, чтобы они могли исправить проблемы.
Собранные отзывы необходимо приоритизировать на основе их влияния на функциональность программного обеспечения и серьезности проблемы. Это помогает сосредоточить ресурсы на устранении критических проблем, которые могут мешать работе пользователя и влиять на общее качество. Немаловажно предоставить пользователям ответ на их отзывы от команды разработки — это покажет, что их мнение действительно важно и учитывается, а также способствует созданию доверительных отношений и повышению вовлеченности пользователей в процесс улучшения продукта.
UAT считается успешно завершённым, если все тестовые сценарии выполнены и основные ошибки исправлены. По завершении тестирования составляется акт приёмки, который подписывается заказчиком. Это означает, что продукт готов к использованию.
К слову, не обязательно исправлять все баги досконально. Как подчеркивает эксперт в сфере электронной коммерции Шамоли Мия, для всех ошибок, оставшихся до запуска, можно согласовать дату их устранения, чтобы они не оставались постоянными проблемами.
«Фаза UAT может быть названа успешной, когда все тикеты (заявки на исправление ошибок) были отработаны или, по крайней мере, организованы в корзины для доставки перед запуском. Главное здесь — организация — обеспечить видимость плана доставки для каждого собранного тикета», — говорит она.
Бизнес-аналитик играет важную роль в UAT, поддерживая пользователей и объясняя цели тестирования. Он также участвует в обсуждениях с заказчиком по выявленным проблемам и помогает принять решение о готовности продукта.
