Uat тестирование что это
UAT-тестирование
User Acceptance Testing (UAT) — это приемочное тестирование, которое проводится конечными пользователями системы для принятия решения по внедрению. При любой разработке или доработке программного обеспечения есть заключительная стадия такого тестирования, причем оно проводится не профессиональными тестировщиками, а обычными пользователями. Так как обычный пользователь не может полноценно проверить совершенные доработки, важно проводить UAT-тестирование по заранее подготовленным сценариям. Они повышают качество проверки и существенно облегчают задачу конечных пользователей.
Наша компания имеет большой опыт работы в сфере проведения приемочного пользовательского тестирования. Мы обеспечиваем все необходимое для эффективной проверки программного обеспечения конечными пользователями. Чтобы пользовательское тестирование прошло с максимальной эффективностью, наши специалисты решают множество задач:
Благодаря большому опыту и профессионализму наших сотрудников вы можете рассчитывать на грамотное планирование процесса приемки и проведение тестирование программного продукта на высоком уровне. Мы помогали в проведении UAT-тестирования предприятиям разного масштаба, в том числе компаниям с большим количеством подразделений и участников таких тестов. Доверив тестирование нам, вы можете рассчитывать на его проведение в короткие сроки. Нагрузка на пользователей будет минимальной, так как опытная команда тестировщиков проведет все подготовительные работы. Мы добиваемся максимального качества приемочного тестирования, оказывая всестороннюю поддержку пользователям системы в подготовке и проведении испытаний.
Когда нужно качественное и оперативное выполнение приемочного пользовательского тестирования, пользуются услугами нашей компании. На стоимость проверки влияет много факторов. Свяжитесь с нами, чтобы узнать подробнее о нюансах приемочного тестирования и о том, что влияет на цену данной услуги.
Пользовательское приемочное тестирование: руководство по успешному запуску новых продуктов
Как бы банально это не звучало, но большинству людей нравится, чтобы все было просто. Особенно, когда дело касается новых продуктов. По сути, потенциальная ценность, которую ваш продукт или сервис может привнести в жизни в ваших клиентов, не имеет никакого значения, если люди не смогут использовать его так, как этого хочется им, они почти наверняка пройдут мимо и обратят внимание на другие решения.
Напрашивается вывод — прежде чем начинать продавать свой продукт целевым клиентам, вы должны убедиться в том, что они смогут работать с ним так, как и намеревались изначально.
Именно здесь вам может пригодиться пользовательское приемочное тестирование (User Acceptance Testing, UAT). В сегодняшней статье мы расскажем вам, что это такое, когда и как вам следует использовать данный метод и почему он играет столь важную роль при выводе продукта на рынок.
Содержание статьи
Что такое пользовательское приемочное тестирование?
Пользовательское приемочное тестирование — процесс, в ходе которого вы просите группу людей использовать продукт, сервис или часть софта с его полным функционалом.
Известное также как бета-тестирование, UAT служит трем основным целям:
Далее в статье мы еще поговорим о важности UAT, но сперва давайте быстро разберем разные типы такого тестирования.
5 типов пользовательского приемочного тестирования
1. Первый тип, на котором мы и будем фокусироваться в этом посте, — альфа/бета-тестирование. При альфа-тесте роль пользователей на себя берут штатные сотрудники и члены команды разработчиков. А вот бета-тест проводится с участием реальных, специально отобранных пользователей. Ниже — пример лендинга с предложением зарегистрироваться для бета-тестирования Division 2, анонсированного на E3:
Эта страница не очень удачно выглядит в русской реализации, но, тем не менее, она выполняет свою функцию. Быстро и без особых усилий создать свой лендинг пейдж для бета-тестирования вашего нового продукта можно с помощью нашей платформы. Для этого достаточно выбрать любой бесплатный шаблон и адаптировать его под себя:
2. Контрактное приемочное тестирование (contractual acceptance testing) нацелено на то, чтобы проверить, соответствует ли разработанный продукт контрактным требованиям, согласованным всеми заинтересованными сторонами. Обычно такое тестирование используют, дабы убедиться в том, что сторонняя команда разработчиков выполнила свои договорные обязательства.
3. Законодательное приемочное тестирование (regulation acceptance testing) позволяет убедиться в том, что продукт соответствует всем законам и предписаниям своей отрасли и юрисдикции. Такое тестирование следует проводить в сферах здравоохранения и финансов, кроме того, с внедрением GDPR на нем должны акцентировать внимание все европейские компании.
4. Операционное приемочное тестирование (operational acceptance testing) сосредоточено на определении эффективности закулисных процессов внутри организации, которые гарантируют людям полноценное использование продукта. С помощью этого типа тестирования оцениваются такие процессы, как онбординг, сбор данных и защитные механизмы.
5. Тестирование по стратегии черного ящика (black box testing) ориентировано на анализ причинно-следственной связи между взаимодействием пользователя с продуктом и результатом, полученным за счет этого взаимодействия. Этот тип тестирования связан с UAT тем, что здесь людям говорят, для чего предназначен продукт, но изучать, как именно он работает, они могут самостоятельно.
Почему пользовательское приемочное тестирование играет столь важную роль
Итак, UAT является неотъемлемой частью процесса создания продукта. Тем не менее, вы должны фокусироваться на таких тестах не только при их фактическом проведении, но и на всех этапах разработки:
Как видно из диаграммы выше, пользовательское приемочное тестирование нацелено на то, чтобы все изначальные требования к продукту были соблюдены.
Думайте о конечном пользователе
Ценность вашего продукта определяется только людьми, которые будут с ним работать.
Хотя это звучит весьма очевидно, в процессе разработки продукта о таком нюансе можно запросто забыть. Не учитывая то, как ваши конечные пользователь будут взаимодействовать с вашим продуктом, вы рискуете столкнуться со многими проблемами или даже отклониться от намеченного пути. И точно также, не зная, чего на самом деле конечные пользователи хотят от вашего продукта, вы рискуете снабдить его совершенно ненужными функциями.
Несмотря на то, что удерживать фокус на клиентах в ходе разработки можно по-разному, акцентируя внимание на UAT, вы гарантированно сможете убедиться в том, что все усилия по вашему продукту делаются с мыслью о конечном пользователе.
Кроме того, это поможет вам сделать процесс разработки менее произвольным, поскольку каждое изменение или улучшение будет сопровождаться вопросом: «Как эта функция поведет себя в ходе пользовательского приемочного тестирования?».
Подтвердите product/market fit
Положительные результаты, полученные бета-тестерами во время вашего UAT, могут подтвердить не только наличие рынка для вашего продукта, но и то, что потребители в рамках этого рынка будут успешно использовать ваше решение.
Когда продукт готов к проведению UAT?
Прежде чем начинать UAT, команда разработчиков должна соблюсти ряд предварительных условий.
Остановимся на этих критериях более подробно.
Бизнес-требования должны быть готовы
Согласно iSixSigma, главным образом документы по бизнес-требованиям создаются, чтобы:
Продукт должен функционировать на своих предельных возможностях
Пользовательское приемочное тестирование не является синонимом функционального теста. UAT не предназначено для выявления сбоев, ошибок, зависаний и прочих проблем.
Вместо этого, с помощью таких тестов вы должны проверять юзабилити продукта, когда он работает так, как вы и задумывали изначально. Иными словами, если на текущий момент ваше решение нуждается в каких-то очевидных доработках, оно не готово к UAT.
Проблемы должны фиксироваться, исправляться и тестироваться
По ходу разработки продукта вы почти наверняка столкнетесь с перечисленными выше проблемами. Чтобы подготовить свое решение к UAT, ваша команда должна не только исправлять эти просчеты, но и фиксировать их в специальном лог-файле.
Этот лог-файл должен содержать следующую информацию:
Такой подход обеспечивает максимальную прозрачность и наглядность в контексте разработки продукта для всех заинтересованных сторон.
Команда по тестированию системы должна дать добро
На данном этапе производственного процесса, когда все остальные критерии уже были соблюдены, команда разработчиков и другие заинтересованные стороны должны подтвердить готовность продукта к бета-запуску для ограниченного количества пользователей.
Зачем нужно пользовательское тестирование: кейс от Feedly
6 шагов успешного пользовательского приемочного тестирования
Процесс UAT включает в себя следующие этапы:
1. Проанализируйте бизнес-требования
Как было сказано ранее, прежде чем переходить к разработке продукта, вам необходимо позаботиться о документации по бизнес-требованиям. Но помимо этих документов, вам нужно собрать следующее:
Анализируя эти документы, вы сможете начать разработку тестовых сценариев — важнейшего аспекта всех последующих шагов процесса.
2. Разработайте UAT план
На этой стадии вы определяете такие логистические критерии UAT, как:
3. Определите тестовые сценарии и кейсы
Вам нужно будет продумать конкретные задачи для своих бета-тестеров и подготовить учебные материалы, которые бы помогали им пройти этот путь.
По сути, вы должны разрабатывать такие тестовые сценарии так же, как и свой onboarding-процесс. Таким образом вы убедитесь в том, что ваше бета-тестирование соответствует тому, как продукт будет использоваться в реальных условиях.
4. Подготовьте тестовые данные
Разумеется, вы также должны наладить процесс, который бы позволял вам эффективно собирать и подготавливать тестовые данные. Кроме этого, вам нужно быть уверенными в том, что используемая вами информация всегда будет оставаться конфиденциальной (особенно учитывая то, что GDPR уже вступил в силу в Европе).
5. Проведите тест
В ходе тестирования члены QA команды работают с бета-пользователями, чтобы завершить обозначенные тестовые задачи. Как только юзер достигает точки выхода, его просят оценить полученный опыт как позитивный или негативный.
Если большая часть ответов оказывается положительной, команда может уверенно двигаться вперед и выводить продукт на рынок, создав посадочную страницу, открытую уже для всех желающих. Если же это не так — разработчикам придется внедрять в продукт необходимые изменения.
Также стоит отметить, что хотя к этому моменту ваш сервис уже должен нормально функционировать, во время UAT ваши бета-тестеры могут столкнуться с непредвиденными проблемами. Если это произойдет, вам нужно будет приостановить тестирование и возобновить его после устранения неполадок.
6. Подтвердите достижение бизнес-целей
Как только бета-пользователи дадут вам положительную обратную связь, вам нужно будет подготовить документацию, которая послужит официальным сигналом для вывода вашего продукта на рынок.
Эта документация включает:
Затем эти документы представят на встрече по UAT, где будут присутствовать все заинтересованные стороны. Помимо рассмотрения самих документов, участники собрания должны будут убедиться в том, что продукт действительно готов к запуску и что закулисные бизнес-процессы компании гарантируют его стабильную работу.
Практика организации UAT в банке
Если вы координатор UAT (User Acceptance Testing) или тест-менеджер, который находится в поиске решений по организации процессов – эта статья для вас. Данный материал также будет полезен тестировщикам, которые хотели бы узнать пару практических приёмов по организации UAT.
Итак, что же такое UAT-тестирование или, как его еще называют, приёмо-сдаточное тестирование? Это комплексное тестирование пользователями системы на предмет её соответствия требованиям. UAT состоит из этапов:
Во время подготовки UAT-команда получает доступы, изучает функциональность и пишет кейсы. В ходе этапа проверки проводится непосредственно тестирование и принимается конечное решение о внедрении протестированной функциональности.
На мой взгляд, роль тест-менеджера заключается не только в информировании о старте тестирования и сборе результатов по завершению работ. Данный специалист также отвечает за подготовку к тестированию, обучение коллег и оперативное решение проблем, возникающих у пользователей.
Далее я более подробно расскажу об этапах работы тест-менеджера, опишу их особенности, а также постараюсь объяснить, зачем они нужны и какую пользу можно получить, применяя их.
Подготовка
Формирование состава UAT-команды
Первым делом необходимо определить состав UAT-команды, которая будет принимать участие в тестировании. Сделать это лучше заранее, например, еще на этапе функционального тестирования. Таким образом организовать доступы к системам и тестовым стендам, пока занятость тест-менеджера относительно невысока.
Создание Тестовой модели
Следующий шаг – написание UAT-кейсов для проведения тестирования. Для этого должны быть привлечены бизнес-пользователи, которые будут работать с данными кейсами. В дальнейшем это поможет сократить сроки тестирования. Пользователи уже будут знать, что необходимо проверить, и им не придётся лишний раз обращаться к автору тест-кейсов за разбором и пониманием того «что же мы всё-таки тестируем». Возрастает ответственность пользователей, что приводит к более полному покрытию и глубокому пониманию требований.
Согласование Тестовой модели
После того как тестовая модель готова, необходимо привлечь бизнес-аналитика (далее БА) к проверке и согласованию UAT-кейсов, для того, чтобы убедиться, что все требования верно поняты командой UAT и покрыты кейсами. Подобное дополнительное «звено» проверки снизит риски возникновения инцидентов в будущем. Также это сократит сроки UAT-тестирования. В случае, если недостающие кейсы были написаны в процессе прохождения проверок.
Определение сроков проведения UAT-тестирования
После того как все кейсы написаны, согласованы и занесены в баг-трекер, необходимо определить сроки старта работ. Это лучше делать в начале интеграционного тестирования, либо в момент, когда основная часть интеграции уже завершена и есть сроки на поставку тестовой версии продукта в UAT.
Согласовывать сроки лучше всего письменно (e-mail), с подтверждением от руководителя бизнес-пользователей. Это поможет сделать процесс более прозрачным, а также наметить сроки выхода в продуктив и дату закрытия проекта. В свою очередь, пользователи смогут спланировать работу с учётом предстоящей активности, а тест-менеджер получит обратную связь о возможных изменениях в команде (отпуск, болезнь, новый сотрудник и т.д.) и минимизирует риски (оформит новый доступ до начала работ, изменит срок UAT и прочее).
Выделение тестировщика на поддержку UAT
Перед стартом работ для сопровождения UAT-тестирования, я рекомендую выделить тестировщика (или нескольких тестировщиков) из ответственной команды. Это необходимо для подготовки тестовых данных, консультации UAT-команды в момент тестирования, а также позволит бизнес-пользователям вовремя получать ответы на вопросы, соблюдать сроки и не заводить «ложные» дефекты.
Проверка функционала
Выполнение UAT
UAT-тестирование можно проводить одним из следующих способов:
Тестирование по кейсам и критериям ничем не отличаются от обычного системного тестирования, проводимого тестировщиками, только выполняют их бизнес-пользователи. По этой причине я бы хотел остановиться на третьем способе.
При работе в формате Demo достаточно получить от бизнес-пользователей названия проверок, которые необходимо сделать, и далее организовать встречу в помещении с проектором (если в UAT-команде свыше 5 человек) для показа того, как работает функциональность. Это упростит работу — не нужно будет оформлять доступы, контролировать как написание и согласование тестовой модели, так и процесс прохождения сценариев. Также это позволит коллегам уточнить вопросы сразу у команды исполнителя, сформировать замечания и сэкономить общее время.
Данный способ не пользуется популярностью по причине того, что на Demo (которое длится 1,5-2 часа) невозможно охватить всю необходимую функциональность. В итоге приходится проводить UAT-тестирование по кейсам или критериям приемки. Но если на проекте требуется протестировать ограниченный объём функциональности, и имеется большая команда пользователей, формат Demo может оказаться очень полезным.
Контроль UAT-тестирования
Зачастую тест-менеджер не имеет рычагов давления на бизнес-пользователей в условиях «простоя» или сдвига сроков тестирования. В этом случае я рекомендую использовать ежедневное информирование бизнес-заказчика (руководство со стороны бизнес-пользователей), с отправкой копии исполнителю.
С момента старта UAT-тестирования я формирую отчет на основе пройденных кейсов к оставшемуся в процентном соотношении, в котором показаны задачи с простоем, описаны проблемы и риски. Отчет выложен в Confluence, где его может увидеть каждый участник проекта. Это позволяет держать все заинтересованные стороны в курсе текущих дел, а исполнителя UAT-тестирования стимулирует для более ответственного отношения к обязанностям. В итоге в коллективе не создается нервозная обстановка, как, например, в случае с ежедневным прессингом со стороны тест-менеджера. Это позволяет своевременно отреагировать на возникающие проблемы.
На рисунке ниже представлен пример того, как я контролирую процесс UAT в разрезе задач и их ежедневного выполнения.
Можете использовать этот пример или любой удобный для вас способ, который позволит вам сделать процесс более прозрачным и эффективным.
Сложности, возникающие при организации UAT-тестирования
На большинстве проектов я сталкиваюсь с типовым блоком проблем. Чаще всего команда UAT:
В первом случае, когда команда не умеет работать с баг-трекинговой системой, я пишу для них инструкцию, в которой подробно описываю, как создать кейс (критерий приемки) и дефект. Если команда небольшая, то показываю на рабочем месте.
Если команда не хочет работать с TMS, то выходов тут немного. Как правило, UAT-пользователи не работают с подобными системами, потому что привыкли вести свою отчетность в ином виде (Excel, Word, отчет в Confluence и т.п.). На этот случай, по завершению работ, я прошу предоставить отчет о прохождении в любой удобной для них форме, но с указанием проверок и их статусов. Это позволяет понять, что же коллеги проверили, и получить документ о результатах тестирования.
И, наконец, если коллеги не успевают тестировать в согласованные сроки, не идут на контакт и постоянно заняты чем-то другим, рекомендую обраться к пункту Контроль UAT-тестирования этой статьи.
Если вы дошли до этого абзаца, значит дочитали статью до конца и, возможно, она вам даже понравилась. Надеюсь, что данный материал помог вам узнать что-то новое и полезное. Делитесь своим опытом в комментариях. Всем отличного настроения и интересных проектов!
Uat тестирование что это
Пользовательское приемочное тестирование (UAT) — это тип тестирования, выполняемый конечным пользователем или клиентом для проверки / принятия системы программного обеспечения перед перемещением приложения в производственную среду. UAT выполняется на заключительном этапе тестирования после выполнения функциональных, интеграционных и системных испытаний.
Основной целью UAT является проверка сквозного бизнес-потока. Он не фокусируется на косметических ошибках, орфографических ошибках или тестировании системы. Приемочное тестирование пользователя выполняется в отдельной среде тестирования с настройкой данных, аналогичных производственным. Это своего рода тестирование черного ящика, в котором будут участвовать два или более конечных пользователя. Полная форма UAT — это приемочные испытания.
Кто выполняет UAT?
Необходимость приемочного тестирования:
После того, как программное обеспечение прошло модульное, интеграционное и системное тестирование, необходимость приемочного тестирования может показаться излишней. Но приемочные испытания необходимы, потому что
Приемочные испытания и V-модель
В VModel приемочное тестирование пользователя соответствует фазе требований жизненного цикла разработки программного обеспечения (SDLC).
Предварительные условия приемочного тестирования:
Ниже приведены критерии входа для приемочного тестирования:
Как сделать UAT-тестирование
UAT выполняется предполагаемыми пользователями системы или программного обеспечения. Этот тип тестирования программного обеспечения обычно проводится на клиентском компьютере, который называется бета-тестированием. Как только критерии входа для UAT удовлетворены, тестировщикам необходимо выполнить следующие задачи:
Шаг 1) Анализ бизнес-требований
Одним из наиболее важных действий в UAT является выявление и разработка сценариев тестирования. Эти тестовые сценарии получены из следующих документов:
Шаг 2) Создание плана UAT:
Шаг 3) Определите тестовые сценарии и тестовые случаи:
Определите сценарии тестирования в отношении бизнес-процесса высокого уровня и создайте контрольные примеры с четкими шагами тестирования. Тестовые случаи должны в достаточной степени охватывать большинство сценариев UAT. Бизнес-прецеденты являются входными данными для создания тестовых случаев.
Шаг 4) Подготовка тестовых данных:
Шаг 5) Запустите и запишите результаты:
Выполните тестовые случаи и сообщите об ошибках, если таковые имеются. Повторно проверьте ошибки, как только исправлены. Инструменты управления тестами могут быть использованы для выполнения.
Шаг 6) Подтверждение достигнутых бизнес-целей:
Бизнес-аналитики или UAT-тестеры должны отправить подпись после тестирования UAT. После подписания товар годится для производства. Результатами тестирования UAT являются План тестирования, Сценарии и сценарии тестирования UAT, Результаты испытаний и Журнал дефектов.
Критерии выхода по UAT:
Перед переходом в производство необходимо учитывать следующее:
Качества тестеров UAT:
Тестировщик или бизнес-аналитик или специалист по предмету Эксперты, которые понимают бизнес-требования или процессы, могут подготовить тест и данные, которые являются реалистичными для бизнеса.
Лучшие практики:
Для достижения успеха UAT необходимо учитывать следующие моменты:
UAT Инструменты
На рынке существует несколько инструментов, используемых для приемочного тестирования Пользователем, и некоторые из них перечислены для справки:
Фитнес-инструмент: это Java- инструмент, используемый в качестве движка для тестирования. Легко создавать тесты и записывать результаты в таблицу. Пользователи инструмента вводят форматированный ввод и тесты создаются автоматически. Затем выполняются тесты, и результат возвращается пользователю.
Watir : Это инструментарий, используемый для автоматизации браузерных тестов во время приемочного тестирования. Ruby — это язык программирования, используемый для межпроцессного взаимодействия между ruby и Internet Explorer.
UAT тестирование
Прежде чем продавать продукт целевым клиентам, нужно убедиться в том, что пользователи смогут работать с ним так, как этого хочется им. Для этого и пригодится пользовательское приемочное тестирование (User Acceptance Testing). Что это такое, когда и как его использовать — в нашей статье.
Что такое UAT
Это процесс, при котором группа людей изучает эффективность сервиса, его функционала. Другое название — бета-тестирование.
UAT нужен для того, чтобы:
понять, как ведет себя продукт в реальных условиях, соответствует ли результат задумке;
выявить, были ли добавлены все возможные функции;
проверить, есть ли ошибки, которые будут мешать пользователю.
Роль UAT
Тестирование — это одна из составных частей создания проекта. Разработчик продукта должен заострить внимание на каждом из рабочих этапов:
Иллюстрация показывает, что пользовательское тестирование контроля за соблюдением всех поставленных требований к проекту.
Типы пользовательского приемочного тестирования
UAT тестирование делится на виды:
На этапе альфа вместо пользователей продукт тестируют сотрудники и другие приближенные к проекту люди. Бета-тест — это следующий шаг, когда для проверки собирается группа потенциальных клиентов. Например, когда разработчики игр рассылают приглашения на тематические ресурсы, чтобы набрать людей.
Контрактное приемочное тестирование.
Используется для проверки: соответствует ли проект всем требованиям соглашения между всеми участниками. Чаще всего процесс необходим при работе с наемной командой разработчиков. Заказчику нужно убедиться, что подрядчик реализовал все задачи.
Законодательное приемочное тестирование.
Помогает удостовериться в том, что продукт не нарушает законы и соответствует всем нормам в пределах конкретной отрасли. Чаще всего проверка нужна для проектов в сфере здравоохранения и финансов.
Операционное приемочное тестирование.
Определяет эффективность процессов, которые происходят вне видимости клиента (внутри компании), но необходимы для реализации всех функций продукта. Этот тип помогает проанализировать сбор данных, защитные системы и так далее.
Тестирование по стратегии черного ящика.
Предназначен для изучения причинно-следственной связи между пользовательским взаимодействием с продуктом и результатом, который получается за счет этого. На этом этапе людям объясняют, для чего предназначен продукт, но как именно он работает они изучают самостоятельно.
Когда продукт готов к проведению UAT
Пользовательское тестирование нельзя начинать только по собственному желанию. Продукт должен быть готов к нему. Для этого соблюдаются некоторые условия:
Четко сформулировать бизнес-требования.
Требования излагаются в документах user acceptance testing, чтобы:
все стороны пришли к соглашению;
сформулировать, как разработчики видят продукт;
собрать информацию для следующих стадий работы;
описать, как продукт решит проблемы пользователей, удовлетворит потребности бизнеса и клиентов.
Продукт должен работать на максимум.
UAT testing не относится к функциональным тестам. Он не пригоден для поиска сбоев в работе, багов и ошибок. Вместо этого пользовательское тестирование нацелено на юзабилити — функционирует ли все таким образом, как это было задумано. Если на данный момент проект требует доработок, то он еще сырой для UAT.
Ошибки нужно регистрировать, исправлять и повторно тестировать.
При разработке продукта команда столкнется с проблемами. Для подготовки к пользовательскому тестированию их нужно не только исправлять, но и фиксировать в отдельном файле:
в чем была проблема;
подтверждение, что проводилось тестирование;
Такой метод создает прозрачную структуру и наглядность работы, которая удовлетворит все заинтересованные стороны.
Тестовая команда должна одобрить.
На этом этапе команда разработчиков и остальные стороны проекта подтверждают готовность к бета-запуску среди ограниченного круга пользователей.
Как провести пользовательское приемочное тестирование
User acceptance testing требует соблюдения правил:
План, требования и сроки.
Нужно подготовить план работ и ознакомить с ним все стороны, команду разработчиков. Рекомендуется в письме указать детали, сроки и цели тестирования, затем собрать конференцию с участниками, чтобы выделить основные моменты.
Всю информацию для теста нужно подготовить заранее, чтобы у пользователей не было проблем. В работе могут понадобится объемные таблицы данных, описание параметров.
Настройка тестируемой среды.
В процессе проверок нужно подготовить среду: инсталлировать ПО, софт, настроить программу. Во время тестов может понадобится периодически возвращать продукт в исходное состояние. Чтобы не возникало проблем, пользователям нужно дать инструкции.
У пользователей всегда в доступе должны быть требования к системе, сопроводительные бумаги (даже «help»). Исходная информация позволит команде находить неточности и ошибки.
Контакты для сопровождения.
Пользователям нужно дать контакты лиц, ответственных за поддержку. Если они найдут ошибку, то должны знать, к кому им обращаться.
Участникам тестирования нужно объяснить, кто ответственен за:
требования к продуктам;
технические моменты, связанные с ПО;
вопросы по тестированию;
права, доступы, аккаунты;
установку софта и настройку тестируемой среды.
Нужно дать пользователям информацию о статусе тестирования: какие работы были проделаны, где будут задержки, какие ошибки выявлены. Так они смогут оценить общую картину и понять свою задачу.
Отчет и итоги пользовательского тестирования.
Пользователям нужно предоставить финальный отчет. Он должен показать, на что повлияла работа. В отчете указывают:
какие проблемы были выявлены, их оценка;
планы по исправлению недочетов;
этапы планируемой оптимизации и будущих тестов;
результат приема работы и последующие шаги: будет ли одобрена версия для выпуска, планируется ли доработка.
Дополнительное общение с пользователями.
Нужно наладить неформальное общение с участниками процесса. Это могут быть звонки с вопросами о том, как идет работа, есть ли трудности и даже простое «как дела».
Заключение
User acceptance testing — это емкий и важный процесс для подготовки проекта к выпуску. Следуя правилам, можно предоставить пользователям и заказчикам качественный, отлично протестированный и отлаженный продукт. Если тестирование крупное, можно подключить профессиональных тестировщиков.