Практика организации 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-тестирование можно проводить одним из следующих способов:

  • Тестирование по кейсам в Test Management System.
  • Тестирование по критериям приемки.
  • В формате Demo.

Тестирование по кейсам и критериям ничем не отличаются от обычного системного тестирования, проводимого тестировщиками, только выполняют их бизнес-пользователи. По этой причине я бы хотел остановиться на третьем способе.

При работе в формате Demo достаточно получить от бизнес-пользователей названия проверок, которые необходимо сделать, и далее организовать встречу в помещении с проектором (если в UAT-команде свыше 5 человек) для показа того, как работает функциональность. Это упростит работу — не нужно будет оформлять доступы, контролировать как написание и согласование тестовой модели, так и процесс прохождения сценариев. Также это позволит коллегам уточнить вопросы сразу у команды исполнителя, сформировать замечания и сэкономить общее время.

Данный способ не пользуется популярностью по причине того, что на Demo (которое длится 1,5-2 часа) невозможно охватить всю необходимую функциональность. В итоге приходится проводить UAT-тестирование по кейсам или критериям приемки. Но если на проекте требуется протестировать ограниченный объём функциональности, и имеется большая команда пользователей, формат Demo может оказаться очень полезным.

Контроль UAT-тестирования

Зачастую тест-менеджер не имеет рычагов давления на бизнес-пользователей в условиях «простоя» или сдвига сроков тестирования. В этом случае я рекомендую использовать ежедневное информирование бизнес-заказчика (руководство со стороны бизнес-пользователей), с отправкой копии исполнителю.

С момента старта UAT-тестирования я формирую отчет на основе пройденных кейсов к оставшемуся в процентном соотношении, в котором показаны задачи с простоем, описаны проблемы и риски. Отчет выложен в Confluence, где его может увидеть каждый участник проекта. Это позволяет держать все заинтересованные стороны в курсе текущих дел, а исполнителя UAT-тестирования стимулирует для более ответственного отношения к обязанностям. В итоге в коллективе не создается нервозная обстановка, как, например, в случае с ежедневным прессингом со стороны тест-менеджера. Это позволяет своевременно отреагировать на возникающие проблемы.

На рисунке ниже представлен пример того, как я контролирую процесс UAT в разрезе задач и их ежедневного выполнения.

Можете использовать этот пример или любой удобный для вас способ, который позволит вам сделать процесс более прозрачным и эффективным.

Сложности, возникающие при организации UAT-тестирования

На большинстве проектов я сталкиваюсь с типовым блоком проблем. Чаще всего команда UAT:

  • не умеет работать с TMS;
  • не хочет работать с TMS;
  • не располагает временем на тестирование или не успевает протестировать в согласованные сроки.

В первом случае, когда команда не умеет работать с баг-трекинговой системой, я пишу для них инструкцию, в которой подробно описываю, как создать кейс (критерий приемки) и дефект. Если команда небольшая, то показываю на рабочем месте.

Если команда не хочет работать с TMS, то выходов тут немного. Как правило, UAT-пользователи не работают с подобными системами, потому что привыкли вести свою отчетность в ином виде (Excel, Word, отчет в Confluence и т.п.). На этот случай, по завершению работ, я прошу предоставить отчет о прохождении в любой удобной для них форме, но с указанием проверок и их статусов. Это позволяет понять, что же коллеги проверили, и получить документ о результатах тестирования.

И, наконец, если коллеги не успевают тестировать в согласованные сроки, не идут на контакт и постоянно заняты чем-то другим, рекомендую обраться к пункту Контроль UAT-тестирования этой статьи.

Если вы дошли до этого абзаца, значит дочитали статью до конца и, возможно, она вам даже понравилась. Надеюсь, что данный материал помог вам узнать что-то новое и полезное. Делитесь своим опытом в комментариях. Всем отличного настроения и интересных проектов!

comments powered by HyperComments
Автор полностью отражает свои собственные взгляды (за исключением маловероятных случаев гипноза), которые могут не совпадать с точкой зрения Перфоманс Лаб.