что такое 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 так, чтобы участники остались удовлетворены результатом?

Рассмотрим такой важный вопрос как организация и проведение UAT. При этом посмотрим, как провести приемочное тестирование максимально эффективно с точки зрения выявления дефектов и оставить отличное впечатление у непосредственных участников процесса.

Конечно, самый простой и лежащий на поверхности ответ, это предоставить пользователям и заказчикам для приемки качественный, отлично протестированный и отлаженный продукт. Если нет ошибок, все отлично работает, то естественно участники UAT будут удовлетворены таким ПО. Однако, качество самого продукта, это не единственный залог успешной приемки и удовлетворенности пользователей. Какие же еще условия необходимо соблюсти, чтобы пользователи участвующие в UAT остались довольны результатами?

Тут очень важен сам процесс проведения UAT, его организация. Этот процесс должен быть удобен и понятен для участников, не должен вызывать у них отторжения и недоверия, пользователям важно увидеть реальную значимость этой процедуры. Грамотная организация приемочного тестирования очень важна ведь пользователи должны воспринимать UAT не как формальную и обременительную процедуру, а по настоящему включиться в процесс тестирования и помочь выявить какие-то проблемы, не очевидные для ИТ тестирования.

Итак, оставим за скобками требования к уровню качества ПО, которое передается на UAT и посмотрим на остальные факторы. Ниже я приведу 8 правил, которые позволят организовать приемочное тестирование так, чтобы участники остались удовлетворены самим процессом и внесли максимальный вклад в контроль качества:

Источник

UAT тестирование

Прежде чем продавать продукт целевым клиентам, нужно убедиться в том, что пользователи смогут работать с ним так, как этого хочется им. Для этого и пригодится пользовательское приемочное тестирование (User Acceptance Testing). Что это такое, когда и как его использовать — в нашей статье.

Что такое UAT

Это процесс, при котором группа людей изучает эффективность сервиса, его функционала. Другое название — бета-тестирование.

UAT нужен для того, чтобы:

понять, как ведет себя продукт в реальных условиях, соответствует ли результат задумке;

выявить, были ли добавлены все возможные функции;

проверить, есть ли ошибки, которые будут мешать пользователю.

Роль UAT

Тестирование — это одна из составных частей создания проекта. Разработчик продукта должен заострить внимание на каждом из рабочих этапов:

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

Типы пользовательского приемочного тестирования

UAT тестирование делится на виды:

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

Контрактное приемочное тестирование.

Используется для проверки: соответствует ли проект всем требованиям соглашения между всеми участниками. Чаще всего процесс необходим при работе с наемной командой разработчиков. Заказчику нужно убедиться, что подрядчик реализовал все задачи.

Законодательное приемочное тестирование.

Помогает удостовериться в том, что продукт не нарушает законы и соответствует всем нормам в пределах конкретной отрасли. Чаще всего проверка нужна для проектов в сфере здравоохранения и финансов.

Операционное приемочное тестирование.

Определяет эффективность процессов, которые происходят вне видимости клиента (внутри компании), но необходимы для реализации всех функций продукта. Этот тип помогает проанализировать сбор данных, защитные системы и так далее.

Тестирование по стратегии черного ящика.

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

Когда продукт готов к проведению UAT

Пользовательское тестирование нельзя начинать только по собственному желанию. Продукт должен быть готов к нему. Для этого соблюдаются некоторые условия:

Четко сформулировать бизнес-требования.

Требования излагаются в документах user acceptance testing, чтобы:

все стороны пришли к соглашению;

сформулировать, как разработчики видят продукт;

собрать информацию для следующих стадий работы;

описать, как продукт решит проблемы пользователей, удовлетворит потребности бизнеса и клиентов.

Продукт должен работать на максимум.

UAT testing не относится к функциональным тестам. Он не пригоден для поиска сбоев в работе, багов и ошибок. Вместо этого пользовательское тестирование нацелено на юзабилити — функционирует ли все таким образом, как это было задумано. Если на данный момент проект требует доработок, то он еще сырой для UAT.

Ошибки нужно регистрировать, исправлять и повторно тестировать.

При разработке продукта команда столкнется с проблемами. Для подготовки к пользовательскому тестированию их нужно не только исправлять, но и фиксировать в отдельном файле:

в чем была проблема;

подтверждение, что проводилось тестирование;

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

Тестовая команда должна одобрить.

На этом этапе команда разработчиков и остальные стороны проекта подтверждают готовность к бета-запуску среди ограниченного круга пользователей.

Как провести пользовательское приемочное тестирование

User acceptance testing требует соблюдения правил:

План, требования и сроки.

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

Всю информацию для теста нужно подготовить заранее, чтобы у пользователей не было проблем. В работе могут понадобится объемные таблицы данных, описание параметров.

Настройка тестируемой среды.

В процессе проверок нужно подготовить среду: инсталлировать ПО, софт, настроить программу. Во время тестов может понадобится периодически возвращать продукт в исходное состояние. Чтобы не возникало проблем, пользователям нужно дать инструкции.

У пользователей всегда в доступе должны быть требования к системе, сопроводительные бумаги (даже «help»). Исходная информация позволит команде находить неточности и ошибки.

Контакты для сопровождения.

Пользователям нужно дать контакты лиц, ответственных за поддержку. Если они найдут ошибку, то должны знать, к кому им обращаться.

Участникам тестирования нужно объяснить, кто ответственен за:

требования к продуктам;

технические моменты, связанные с ПО;

вопросы по тестированию;

права, доступы, аккаунты;

установку софта и настройку тестируемой среды.

Нужно дать пользователям информацию о статусе тестирования: какие работы были проделаны, где будут задержки, какие ошибки выявлены. Так они смогут оценить общую картину и понять свою задачу.

Отчет и итоги пользовательского тестирования.

Пользователям нужно предоставить финальный отчет. Он должен показать, на что повлияла работа. В отчете указывают:

какие проблемы были выявлены, их оценка;

планы по исправлению недочетов;

этапы планируемой оптимизации и будущих тестов;

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

Дополнительное общение с пользователями.

Нужно наладить неформальное общение с участниками процесса. Это могут быть звонки с вопросами о том, как идет работа, есть ли трудности и даже простое «как дела».

Заключение

User acceptance testing — это емкий и важный процесс для подготовки проекта к выпуску. Следуя правилам, можно предоставить пользователям и заказчикам качественный, отлично протестированный и отлаженный продукт. Если тестирование крупное, можно подключить профессиональных тестировщиков.

Источник

Пользовательское приемочное тестирование: руководство по успешному запуску новых продуктов

Как бы банально это не звучало, но большинству людей нравится, чтобы все было просто. Особенно, когда дело касается новых продуктов. По сути, потенциальная ценность, которую ваш продукт или сервис может привнести в жизни в ваших клиентов, не имеет никакого значения, если люди не смогут использовать его так, как этого хочется им, они почти наверняка пройдут мимо и обратят внимание на другие решения.

Напрашивается вывод — прежде чем начинать продавать свой продукт целевым клиентам, вы должны убедиться в том, что они смогут работать с ним так, как и намеревались изначально.

Именно здесь вам может пригодиться пользовательское приемочное тестирование (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, где будут присутствовать все заинтересованные стороны. Помимо рассмотрения самих документов, участники собрания должны будут убедиться в том, что продукт действительно готов к запуску и что закулисные бизнес-процессы компании гарантируют его стабильную работу.

Источник

User Acceptance Testing: как менеджеру организовать процесс

Представим себе, что вы ведете проект по разработке программного продукта и уже подошли к этапу, когда минимальный скоуп завершен, релиз-кандидат стабилизирован и настало время релиза. На этом этапе необходим дополнительный шаг, на котором вы еще раз проверите систему вместе с представителями бизнеса и решите, готова ли она к выливке в продакшн. Этот этап называется User Acceptance Testing. Ниже поговорим о том, для чего он нужен, как к нему готовиться и что менеджер проекта должен сделать для его проведения.

Сразу оговорюсь, что речь идет о применении практики UAT в аутсорсинге. Кейс продуктовой компании здесь не рассматривается.

Для чего проводить UAT

Шаг дополнительной проверки системы на таком позднем этапе может показаться излишним: скорее всего, ваш клиент уже имел множество возможностей посмотреть на систему и «пощупать» её в тестовой среде. Видел демо и высказал фидбек, который вы вместе с командой успешно реализовали в последующих спринтах. Более того, ваша команда уже провела всё необходимое тестирование, включая регрессионное, и прошла фазу стабилизации, вычистив максимальное количество дефектов.

Зачем же проверять систему еще раз?

Дело в том, что во время регулярных демо после каждого спринта ваш клиент видел систему только частично и, наверно, проверял её только в разрезе конкретных фич. Также вполне вероятно, что он не уделял такой проверке должного внимания, ведь до релиза было еще далеко. На этапе UAT клиент сможет оценить систему в целом и проверить её в разрезе своих бизнес-процессов, а не фич.

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

Таким образом, UAT — последний фильтр, который система должна пройти перед тем, как стать доступной широкой массе пользователей. По результатам этой фазы клиент может принять два возможных решения: выходить в продакшн или отложить релиз, дав команде время на необходимые доработки, если их не удалось выполнить в рамках UAT.

Сценарии приемки

В предыдущем разделе мы говорили, что во время UAT клиент проверяет систему в разрезе бизнес-процессов. Чтобы сделать этот процесс максимально продуктивным, а также наилучшим образом к нему подготовиться, необходимо составить и согласовать сценарии приемки.

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

Нужны они для того, чтобы спланировать и упорядочить работу клиента по приемке системы и формализовать её. Клиент пройдется по всем сценариям и по каждому из них даст фидбек: все работает или есть какие-то замечания. Более того, при нехватке времени можно выделить наиболее приоритетные сценарии и просмотреть только их — в большинстве случаев этого будет достаточно.

Типичный сценарий приемки включает такую информацию:

Ниже вы найдете пример одного из возможных шаблонов для сценария приемки. Такая таблица используется как на этапе подготовки и согласования сценариев, так и на этапе проведения UAT — клиент заполняет колонки для фидбека.

Вход в фазу UAT

Чтобы продукт можно было отдать на приемку заказчику, релиз-кандидат должен быть достаточно высокого качества. Иначе клиент вместо проверки бизнес-процессов будет заниматься выявлением технических дефектов (неработающая валидация, съехавшая верстка, ошибки 404 и прочее), то есть фактически выполнять работу QA-инженера.

Но «достаточно высокое качество» — понятие абстрактное, его нужно уточнить на этапе планирования проекта или релиза и согласовать с клиентом.

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

UAT может быть начата при условии, что после проверки X% тест-кейсов в системе остаются неустраненными 0 дефектов с уровня blocker, до 3 дефектов с уровнем critical и не более 10 дефектов с уровнем high.

Или другой пример, с более гибкой формулировкой:

UAT может быть начата при условии, что после проверки X% тест-кейсов в системе остаются неустраненными 0 дефектов с уровнем blocker и отсутствуют дефекты, блокирующие проверку сценариев приемки с приоритетом high и medium.

Уровни дефектов также нужно оговорить, иначе вас ждут постоянные споры о том, относится ли данный дефект к уровню normal или high. Значения уровней можно придумать самостоятельно (возможно, у вас в команде или компании уже есть устоявшийся список). Но лучше взять что-то стандартное (например, ISTQB-стандарт c перечнем уровней дефектов найти можно здесь).

Проведение приемки

Проведение приемки происходит по заранее оговоренным сценариям. По каждому шагу/сценарию принимающая сторона должна проставить отметку прохождения (например, pass/fail/pass with comments) и описать обнаруженную проблему. Сделать это можно либо прямо в таблице со сценариями, либо заводя дефект в баг-трекинг систему (Jira, Redmine и так далее) и оставляя номер дефекта в строке с проверяемым шагом.

Для приемки имеет смысл подготовить для клиента отдельную тестовую среду, наполнив её данными, максимально приближенными к реальным. А если вы осуществляете миграцию со старой системы в новую, то лучше наполнить тестовую среду реальными данными клиента, предварительно анонимизировав их.

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

Важный вопрос — кто именно должен проводить приемку со стороны клиента. От этого зависит эффективность процесса и ценность полученных результатов. Распространен вариант, когда приемку выполняет тот же человек, который работал с командой над требованиями, — продукт-оунер. В таком случае приемка, скорее всего, пройдет максимально быстро и с минимальным количеством замечаний. Обратная сторона такого эффекта — продукт-оунер, не являясь конечным пользователем, может не знать о каких-то важных специфических особенностях бизнес-процесса. Тогда проблемы всё равно проявятся, но на более поздней стадии, когда система начнет реально эксплуатироваться, а значит, цена их устранения вырастет.

В связи с этим более предпочтителен вариант, когда приемку проводят конечные пользователи, предварительно прошедшие необходимое обучение и инструктаж. Им нужно будет рассказать о системе, провести несколько демо и ознакомить с процессом. Продукт-оунер в таком случае послужит точкой агрегации всех запросов и замечаний пользователей. Он будет следить за тем, чтобы отчет о приемке был заполнен корректно, и принимать окончательное решение о результатах UAT.

В проведении UAT, как и в любом другом процессе, крайне важна коммуникация: чем быстрее она происходит, тем меньше остается «висячих» вопросов и тем выше шансы сделать все успешно. Очень помогают ежедневные звонки, на которых вы вместе с клиентом проходите по выявленным замечаниям и вопросам, выясняете, появились ли в процессе новые требования или все замечания сводятся к устранению дефектов. Последнее особенно важно, если вы работаете с фиксированными сроками и скоупом. Также эти звонки помогают оперативно согласовать уровни выявленных дефектов и приоритизировать их устранение.

На любом этапе проекта менеджеру необходимо держать основных стейкхолдеров в курсе того, как продвигается работа. И если на этапе активной разработки основной показатель прогресса — это процент выполнения скоупа, то на этапе UAT важно мониторить такие метрики:

Выход из UAT

Редко когда приемка проходит абсолютно гладко. Так или иначе обнаруживаются какие-то нестыковки, возникают вопросы, заводятся дефекты. И хотя часть дефектов можно оставить на пострелизный период, некоторые из них, скорее всего, окажутся важными и срочными и потребуют устранения в рамках UAT.

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

Критерии выхода задают условия, при которых приемка может считаться успешной, а система — допущена к релизу. Как и в критериях входа, здесь имеют значение такие характеристики:

Например, критерий выхода может звучать так:

Система считается готовой к релизу, если:

Конкретные значения, естественно, должны быть согласованы отдельно в каждом конкретном случае. Для мобильной игры критерии могут быть мягкими (здесь более важна скорость выхода на рынок), а медицинская система должна соответствовать очень высоким стандартам качества.

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

При выходе из UAT есть два варианта решения: выходить в продакшн или отложить релиз для устранения дефектов и выполнения необходимых доработок.

При откладывании релиза после внесения необходимых изменений в систему приемка, как правило, не повторяется в полном объеме — перепроверяют только те сценарии, в которые были внесены изменения. После этого обычно следует решение о выходе в продакшн, хотя в некоторых случаях клиент может захотеть выйти на второй круг изменений. Здесь важно не увлекаться бесконечной «полировкой» продукта, ведь можно потерять драгоценное время выхода на рынок. Но окончательное решение остается за клиентом.

Примеры

В заключение приведу несколько примеров проектов из моей личной практики и практики коллег.

Кейс 1 — система для планирования путешествий онлайн

Сценарии приемки отсутствовали, за исключением одной функциональной области, связанной с платежами. При этом она проводилась по группам функций (эпикам). Я бы не рекомендовал так делать (и не делал в дальнейшем на своих проектах). Дело в том, что такой подход не позволяет проверить систему как целое, а ограничивается лишь повторной проверкой функций.

Критерии приемки для каждого эпика звучали так:

При этом эти критерии фактически были как для входа, так и для выхода из UAT: сначала эпик проверяла команда вендора, затем (по тем же критериям) — команда клиента.

Как это часто бывает, основной сложностью при приемке было доказать клиенту, что часть «дефектов» на самом деле это изменения к скоупу. С этой целью до начала работы над релизом был сформирован бейзлайн скоупа и достигнута договоренность с клиентом, что всё, что не описано явно, не входит в скоуп релиза. Также команды вендора и клиента ежедневно созванивались для обсуждения результатов и классификации найденных дефектов: какие-то из них признавались дефектами, некоторые — изменениями к скоупу. По последним клиент решал — сдвинуть релиз или отложить изменения.

Кейс 2 — связка нескольких систем

Здесь несколько команд параллельно разрабатывали несколько систем, обслуживающих смежные бизнес-процессы. Релизы у части систем были совмещены, у части — разнесены во времени. Приемка при этом проводилась так:

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

Даже такое покрытие не страхует вас от трудностей на 100%. В нашем случае неприятным сюрпризом стало внезапное обновление прошивки на POS-терминалах как раз в последний день приемки. Так что версии ПО и аппаратного обеспечения тоже стоит включать в описание сценариев.

Приемка начиналась с совместных сессий с клиентом, потом клиент продолжил уже самостоятельно. Это позволило существенно ускорить процесс. Как и в предыдущем кейсе, велась практика ежедневных звонков для обсуждения результатов приемки и классификации дефектов.

Кейс 3 — Data Science проект

Здесь всё было несколько сложнее, поскольку критерии приемки в такого рода проектах трудно сформулировать так же однозначно, как в проектах традиционной разработки. Команда прошла путь от состояния, когда клиент утверждал: «Система должна работать на любых наборах данных», до более прагматичного подхода, когда определено конечное множество форматов входных данных, на которых система должна работать корректно.

Фактически проводилось два типа приемки: приемка функциональности пользовательского интерфейса по традиционной схеме + приемка качества алгоритма обработки данных.

Изначально для релиза были определены критерии успешности — типичные примеры входных данных, которые система должна была успешно обработать.

В дальнейшем приемка алгоритма проводилась на основании указанных примеров.

Еще раз коротко о главном

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

Источник