Содержание
- Демо и умри!
- Шаг в обувь пользователей
- Краткая история UAT
- UAT говорит вам, насколько полезна система
- Кто может выполнять UAT?
- Нет ошибок, нет стресса - ваше пошаговое руководство по созданию изменяющего жизнь программного обеспечения без разрушения вашей жизни
- Успех и неудачи
- Преимущества UAT
Источник: Лайтком / iStockphoto
вынос:
После того, как программное обеспечение проходит модульное, интеграционное и системное тестирование, необходимость в приемочном тестировании может показаться излишней. Почему приемочное тестирование пользователя (UAT) все еще важно? Здесь хорошо узнать о преимуществах UAT и почему он уникален.
Демо и умри!
Вы когда-нибудь проводили презентацию или тренинг для клиентов, и что-то не получилось? Или вы когда-нибудь давали кому-то набор инструкций и понимали, что что-то упустили, или это не сработало, как вы надеялись? В каждом из этих случаев вы принимаете точку зрения конечного пользователя и работаете с программным обеспечением в этом лице. Скорее всего, вы сделали что-то по-другому, потому что вы думали, как пользователь, а не разработчик.
Шаг в обувь пользователей
Уникальным углом пользовательского приемочного тестирования (UAT) является тестирование программного обеспечения в качестве конечного пользователя. Программное обеспечение построено, чтобы дать пользователям ощутимые результаты. Например, сайты электронной коммерции позволяют покупателям приобретать товары. Когда клиент размещает заказ, программное обеспечение сайтов электронной коммерции уведомляет администратора магазина о том, что выбранный товар может быть извлечен и упакован для отправки. Пользователи программного обеспечения могут быть разных типов, поэтому этот этап тестирования позволяет команде разработчиков убедиться, что конечные пользователи достигают ожидаемых результатов программного обеспечения.
Краткая история UAT
До появления Интернета большая часть программного обеспечения была развернута для известной пользовательской аудитории. Если компания разрабатывала программное обеспечение для клиента, назначенный менеджер имел полномочия проверять, соответствует ли программное обеспечение условиям контракта. Это должно было представлять точку, в которой программное обеспечение «соответствовало цели», что было достигнуто путем выбора представителей конечных пользователей для проведения тестирования и предоставления отчета с результатами. Поскольку пользователи были известной, закрытой группой, каждый из них мог быть обучен использованию программного обеспечения, как правило, с помощью очень подробных этапов тестирования. Девизом дня было то, что больше деталей было лучше.
По мере того, как все больше программного обеспечения разрабатывалось для клиентов в Интернете, аудитория конечных пользователей становилась все более открытой. Уже невозможно было идентифицировать и обучить всех вероятных конечных пользователей, поэтому при разработке программного обеспечения необходимо было уделять гораздо больше внимания удобству использования и быть легко понятным - даже с минимальной предоставленной информацией. Итак, UAT пришлось изменить, чтобы соответствовать этим требованиям.
UAT говорит вам, насколько полезна система
Таким образом, UAT не только говорит нам о степени функциональности для части программного обеспечения, но также говорит о том, насколько она полезна. Большинство UAT лучше всего выполняются людьми, которые понимают целевого конечного пользователя, который будет иметь опыт работы с программным обеспечением с небольшими предварительными знаниями и может дать точное представление о простоте использования программного обеспечения и о том, что нуждается в улучшении.
Кто может выполнять UAT?
Когда разработчики тестируют программное обеспечение, они помнят детали того, как пишется система. Эти знания могут влиять на тестирование, и разработчики могут предпринимать иные шаги, нежели конечные пользователи, такие как более быстрое выполнение шагов или игнорирование мелких деталей, которые конечные пользователи могут счесть запутанными. Таким образом, разработчики не лучшие кандидаты UAT. Так кто же?
Во многих организациях работают специальные группы тестирования, которые не занимаются техническим проектированием и разработкой. Небольшие организации либо распределяют тестирование среди сотрудников, не занимающихся разработкой, например, тех, кто выполняет административные обязанности, либо пользуются услугами сторонней компании. Некоторые организации используют так называемое «тестирование в коридоре», где они буквально вручную отбирают сотрудников, которые активно не работают в проекте, и просят их опробовать систему с точки зрения конечных пользователей. Примером может быть заказ товара онлайн.
После внутреннего тестирования могут проходить этапы пилотного или бета-тестирования, в результате чего программное обеспечение предоставляется небольшим группам «реальных» пользователей, которым предлагается использовать продукт бесплатно или со значительной скидкой, в обмен на подробные отзывы об использовании.
Нет ошибок, нет стресса - ваше пошаговое руководство по созданию изменяющего жизнь программного обеспечения без разрушения вашей жизни
Вы не можете улучшить свои навыки программирования, когда никто не заботится о качестве программного обеспечения.
Прогрессивные этапы UAT с различной аудиторией повышают уверенность в удобстве использования программного обеспечения. В сочетании с этапами итеративной разработки можно выполнить несколько циклов UAT, чтобы протестировать новые функции по мере их предоставления, а также проверить предыдущие функции.
Хорошие тестеры UAT любопытно посмотреть, что произойдет, если они пойдут разными путями к определенной цели. В конце концов, каждый по-разному подходит к использованию программного обеспечения, поэтому, если небольшая группа людей может охватить многие возможности, доверие к программному обеспечению в рабочем режиме выше.
Успех и неудачи
Процессы UAT должны проверить, что каждый тип пользователя программного обеспечения получает ощутимые результаты, необходимые как для успешных, так и для неудачных потоков.
В процессе успеха конечный пользователь уходит с ожидаемым результатом, таким как размещение заказа продукта. В потоке сбоев программное обеспечение поддерживает конечного пользователя в той или иной форме сценария ошибки, например, когда клиент предоставляет неверную информацию об оплате кредитной картой.
Для проверки работоспособности некоторая информация должна быть предоставлена тестерам. В противном случае они не знают, что должно делать программное обеспечение. Но чтобы проверить удобство использования, это должно быть минимальным - только на основе задач или требований, таких как покупка «х» (продукт) и оплата «у» (используя данные кредитной карты). Ответственность за регистрацию наблюдений, успехов и неудач должна быть возложена на тестеров.
Преимущества UAT
Ключевым преимуществом хорошего UAT является то, что он поддерживает текущие расходы на техническое обслуживание как можно ниже. Его дешевле исправить на ранних этапах. Гораздо сложнее исправить ошибку, когда вокруг нее больше кода для регрессионного теста или если первоначальный разработчик недоступен.
UAT, который выполняется в несколько этапов и с различными типами аудитории, обеспечивает оптимальные возможности для выявления и устранения неисправных функций / проблем с удобством использования на ранних этапах тестирования. Сохранение целей UAT на уровне задач и требований позволяет тестировщикам наблюдать и замечать гораздо больше, и даже предпринимать шаги, выходящие за рамки, предусмотренные разработчиками.
Обратная связь с циклами UAT может быть использована для последующих итераций разработки, что повышает надежность и удобство использования программного обеспечения. При надлежащем планировании даже этапы бета-тестирования могут дополнять деятельность по маркетингу и продажам, предоставляя ссылки и отзывы о конкретных примерах.