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.

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

• количество и уровень дефектов в системе;
• допустимое количество и приоритет сценариев, которые имеют статус failed.

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

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

• все сценарии приемки, имеющие приоритет high, в статусе pass;
• более 80% сценариев с приоритетом medium и low имеют статус pass;
• остаются неустраненными 0 дефектов уровня blocker и high и не более 10 дефектов уровня normal.

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

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

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

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

Примеры

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

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

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

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

• отсутствие дефектов уровня critical/blocker/major;
• дефекты более низких уровней могут присутствовать, если они в совокупности не блокируют пользователя в прохождении по основному флоу.

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

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

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

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

• Сценарии писала команда вендора (конкретнее — бизнес-аналитики), их утверждал клиент.
• На двух наиболее критичных системах присутствовали критерии входа/выхода из UAT, сформулированные в количестве дефектов разного уровня + в приоритетах сценариев приемки.
• На тех же двух системах у клиента были четкие временные рамки на осуществление приемки (работа шла с фиксацией сроков релиза).

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

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

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

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

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

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

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

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

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

1. UAT проводится для проверки системы в разрезе бизнес-процессов, а не отдельных фич. При этом система проверяется как целостный механизм. Это позволяет убедиться в том, что ее можно начинать эксплуатировать в реальной жизни.
2. Для входа и выхода из UAT должны быть сформулированы критерии — чаще всего в виде количества/уровня дефектов.
3. UAT лучше всего проводить по предварительно согласованным и приоритизированным сценариям приемки.
4. В ходе UAT важна коммуникация: постоянные митинги для обсуждения прогресса + структурированный репортинг.
5. По результатам UAT клиент может принять решение о выходе в продакшн или о переносе релиза.