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