Что такое uat тестирование
UAT-тестирование
Перед продажей продукта целевым клиентам важно проверить, что люди смогут работать с ним так, как им хочется. Именно для этого проводится UAT-тестирование. Во время него проверяют эффективность сервиса, лично оценивают функционал. Данный процесс также называется бета-тестированием и User Acceptance Testing. По итогам проверки производителю станет ясно, есть ли какие-либо ошибки, которые заметят другие пользователи. Также удастся выяснить, насколько продукт готов к продаже. В данном материале мы разберёмся: UAT-тестирование – что это такое, как проводится и для чего полезно это исследование.
Общая информация
Бета-тестирование выполняет одновременно несколько функций. Главная его задача – подробно изучить сервис, проверить его эффективность и функционал. Этим занимается группа людей, которая обращает внимание на удобство использования продукта.
Во время процесса важно определить, как работает сервис в условиях, приближенных к реальным, устраивает ли разработчиков результат. Также нужно понять, все ли необходимые функции внедрены или чего-то не хватает. Нужно проверить наличие ошибок, которые будут мешать человеку пользоваться продуктом.
Тестирование – обязательный этап создания проекта. Если оно ещё не пройдено, продукт нельзя показывать целевым клиентам. Без проведения такого исследования нет смысла в запуске рекламных кампаний и старте продаж. Не будет гарантий, что проект с успехом стартует, будет полностью отвечает задумке производителя и соответствовать необходимым показателям качества.
Типы тестирования
Тестирование продукта бывает разных типов, и каждый из них имеет свои особенности.
Каждый вид по-своему важен, и многие сервисы проходят каждый этап. Приёмочное тестирование позволит понять, нужно ли что-то менять и дорабатывать.
Когда можно запускать пользовательское тестирование
Разобравшись в определении термина 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-тестирования этой статьи.
Если вы дошли до этого абзаца, значит дочитали статью до конца и, возможно, она вам даже понравилась. Надеюсь, что данный материал помог вам узнать что-то новое и полезное. Делитесь своим опытом в комментариях. Всем отличного настроения и интересных проектов!
Всë, что вам нужно знать об управлении релизами
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.
Что это такое управление релизом?
Управление релизами охватывает все этапы выпуска программного обеспечения, от разработки и тестирования до развертывания. Управление релизом требуется каждый раз, когда запрашивается новый продукт, или даже изменения в продукт существующий. Есть пять основных шагов по управления релизом, которые мы делаем в этой ситуации:
Планирование релиза
Этап планирования в большинстве случаев интенсивен, так как именно на этом этапе весь наш релиз организуется от начала до конца. Надёжный план релиза помогает придерживаться верного пути и обеспечивать надлежащее соблюдение стандартов и требований.
При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.
Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:
Следующий шаг на пути к релизам — создание рабочего процесса, к которому на протяжении всего релиза могут обращаться как наши команды, так и ключевые заинтересованные стороны.
Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:
Как только план утверждается и окончательно оформляется, начинается самое интересное!
Важные аспекты планирования релизов
Создание и использование трейн-релиза звучит здорово, но поддерживать процесс в рабочем состоянии во время планирования трейн-релиза может быть непростым. Вот некоторые детали этого процесса:
Построение релиза
После того как план выпуска готов, можно приступать к тестированию продукта для релиза. Это будет фактическое «тестирование уровня пользователя» продукта на основе изложенных в плане выпуска требований.
В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.
Автоматизируя переход ветки, мы проверяем все пороговые значения производительности, бенчмарк и автоматизации из предыдущих релизов в маркет устанавливаются на текущий как основание сравнения, а трейн-релиз блокируется от дальнейших изменений.
Как только код замораживается, начинается новый цикл разработки, и все участвующие команды начинают новый спринт и продолжают разработку. Самое замечательное в трейн-релизе: все знают о следующем, запланированном релизе, и это помогает людям соответствующим образом планировать свою работу.
Релиз веток и контроль версий
Разработка продукта обычно не останавливается, когда заканчивается разработка для релиза, поэтому первое, о чем мы думаем, это как заморозить тестируемую сборку и в то же время поработать над новыми возможностями для следующего релиза. Что случится, если в сборке релизов появится ошибка? Как исправить ошибку, если вы уже добавили кучу новых вещей до того, как эта ошибка нашлась?
Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.
Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.
Пользовательское приемочное тестирование
Пользовательское приемочное тестирование является наиболее важным шагом для управления релизом из-за объема собранных данных и исправлений, необходимых для того, чтобы сделать сборку именно такой, какой она должна быть для официального запуска.
Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:
Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!
Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.
Подготовка и релиз
Этот шаг заключается в том, чтобы внести последние штрихи в продукт, учитывая все, что было понято при UAT. Подготовка релиза также включает в себя заключительную проверку качества командой по контролю качества. В ходе проверки группа по контролю качества проводит окончательные проверки, чтобы убедиться, что сборка соответствует минимальным стандартам приемки и бизнес-требованиям из плана релиза.
После завершения ревью релиз-группа завершит релиз для начала развертывания. Перед тем, как сборка может быть развернуто в живой среде, она должно быть утверждена соответствующими ответственными командами, такими как команда дизайна. UAT гарантирует, что результат утверждается до передачи на следующий этап.
Развертывание релиза
Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:
В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.
Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.
Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.
Анализ после релиза
Работа по управлению релизом не заканчивается, когда публикуется код, продолжаясь до тех пор, пока вы не будете готовы выпустить релиз снова. Если вы хотите, чтобы ваше приложение было успешным, ему нужно хорошее ревью, вам также нужно следить за релизом в производственной среде, чтобы исправлять ошибки, внедрять функции, которые нужны людям, и решать проблемы пользователей. Для этого мы используем Firebase Crashlytics, где отслеживаем любые сбои, требующие немедленного исправления.
Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.
Подведем итоги
Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:
Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.
Что такое 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.