Приемка пользовательских сценариев без технического жаргона: как описывать проверку так, чтобы бизнес не кивал вслепую
На приемке работ нередко бывает так: команда показывает почти готовую доработку, аналитик рассказывает, что «сценарий отрабатывает корректно», разработчик говорит про статусы, проверки и условия, а представитель бизнеса кивает и отвечает, что все понятно. Через несколько дней после запуска выясняется, что человек понял совсем не то, что ему показывали, или вообще не заметил важную деталь, потому что половину встречи мысленно переводил с языка команды на обычный рабочий язык.
Заказчику на приемке не нужно разбираться во внутреннем устройстве решения. От него требуется другое: подтвердить, что в знакомой рабочей ситуации система ведет себя так, как было согласовано. Поэтому хороший приемочный сценарий должен отвечать на простые вопросы: кто что делает, с какими данными, что должно произойти после этого и как понять, что результат верный.
Сценарий приемки - это не сокращенная версия ТЗ
Если в требованиях написано: «При смене состояния объекта выполнить проверку обязательных реквизитов и запустить процесс согласования по шаблону», переносить эту формулировку в документ для бизнеса почти бесполезно. Пользователь обычно не думает состояниями объекта, шаблонами процесса и условиями запуска. Для него ситуация звучит проще: «Я заполнил договор, отправил его на согласование и жду, что задача уйдет нужному руководителю».
Именно так и стоит строить приемку: не от внутренней логики системы, а от реального рабочего действия.
Начинать лучше с понятной ситуации, а не с проверки функции
Фраза «Проверить создание задачи при выполнении условия X» удобна тому, кто писал требования, но пользователь из нее не всегда понимает, что именно ему предстоит проверить. Намного проще: «Менеджер создает договор на 600 000 рублей и отправляет его на согласование. После отправки задача должна появиться у руководителя отдела продаж».
В такой формулировке сразу видно, кто работает, что именно делает, какие данные важны и какой результат ожидается. Не нужно подробно расписывать весь бизнес-процесс, но исходная точка должна быть понятна. Если поведение зависит от суммы, организации, подразделения, вида договора или статуса, эти значения лучше указать прямо, а не писать «заполнить необходимые реквизиты».
Это особенно важно, когда один и тот же документ может вести себя по-разному. Если в сценарии нет конкретных исходных данных, два пользователя могут выполнить одну проверку по-разному и оба будут уверены, что делали все правильно.
Один сценарий должен проверять одну понятную вещь
Иногда приемочный сценарий превращают в длинную цепочку, где одновременно проверяют создание документа, маршрут, уведомления, права, печатную форму и отчет. Пока все работает, это выглядит удобно. Как только возникает ошибка, уже непонятно, что именно принято, где закончилась одна проверка и с какого места повторять следующую.
Лучше делить по смыслу: отдельно проверить, кому уходит договор; отдельно - что происходит после отказа; отдельно - какие действия доступны пользователю после завершения согласования. Сценарии получаются короче, а если бизнес чем-то недоволен, гораздо легче понять, о каком именно поведении идет речь.
В шагах нужно писать действия пользователя
«Выполнить запись документа и инициировать бизнес-процесс» можно спокойно заменить на «Сохранить договор и нажать "Отправить на согласование"». «Проверить создание связанного объекта» - на «Открыть договор и убедиться, что в нем появилась ссылка на заявку».
Технические детали остаются в материалах команды. Пользователю не нужно знать, какой обработчик сработал, где записалась ссылка и каким запросом система определила согласующего. На приемке проверяется не способ реализации, а результат, который человек увидит в своей работе.
Конечно, бывают случаи, когда технический термин уже привычен бизнесу. Если сотрудники каждый день говорят «маршрут согласования», нет смысла специально заменять эту фразу чем-то более бытовым. Убирать нужно не профессиональные слова как таковые, а те формулировки, которые человеку ничего не объясняют.
Ожидаемый результат должен быть видимым
Фразы «система работает корректно», «маршрут сформирован правильно» и «ошибок нет» почти ничего не дают. Если после отправки договора задача должна появиться у начальника отдела продаж со сроком два рабочих дня, так и нужно написать. Если менеджер во время согласования не может поменять сумму, это тоже должно быть указано.
Удобная проверка всегда заканчивается чем-то, что можно увидеть: появился определенный статус, создана задача у конкретной роли, рассчитана сумма, стал недоступен реквизит, появилась запись в отчете. Тогда человек не просто отвечает «да, вроде нормально», а сравнивает фактический результат с заранее понятным ожиданием.
Не все ошибки нужно тащить на пользовательскую приемку
Показывать только идеальный сценарий тоже неправильно. Если в обычной работе пользователь может отправить договор без обязательного поля, выбрать недопустимое значение или попытаться выполнить действие без нужных прав, эти случаи стоит проверить вместе с бизнесом. А вот внутренние ошибки обмена, редкие технические исключения и десятки пограничных комбинаций остаются зоной тестирования команды.
Иначе встреча превращается в многочасовой прогон тест-кейсов, где бизнес уже не понимает, зачем он присутствует.
Перед каждым сценарием полезно сказать, что именно сейчас принимается
Общий вопрос «Посмотрите, все ли устраивает?» слишком расплывчатый. Пользователь может смотреть на расположение кнопки, тогда как команда ждет от него подтверждения правила выбора согласующего. В итоге прозвучит «все хорошо», но участники будут говорить о разных вещах.
Лучше перед проверкой коротко обозначить цель: «Сейчас смотрим, кому уйдет договор при такой сумме», «Здесь проверяем, что произойдет после отказа», «В этом сценарии нужно подтвердить состав данных в отчете». Такая фраза занимает несколько секунд, зато внимание сразу направлено туда, где действительно нужно решение бизнеса.
Документ для бизнеса не обязан выглядеть как набор тест-кейсов
Таблица с колонками «ID», «Предусловия», «Приоритет», «Фактический результат», «Критичность» и «Идентификатор дефекта» может быть удобна тестировщику, но человеку из бизнеса половина этих полей не нужна. Для него обычно достаточно названия рабочей ситуации, исходных данных, нескольких действий и ожидаемого результата.
Для небольшой доработки один сценарий может занимать три-четыре строки. Для более сложного процесса понадобится подробное описание, но объем должен зависеть от самой задачи, а не от шаблона, который когда-то решили применять ко всему подряд.
Один пример на двух языках
Допустим, в 1С:Документообороте изменили маршрут согласования договора и теперь согласующий зависит от суммы.
Формулировка для команды: «При переводе внутреннего документа в состояние "На согласовании" определить исполнителя по значению реквизита "Сумма". При сумме свыше 500 000 рублей создать задачу руководителю подразделения».
Для аналитика и разработчика здесь все понятно, но пользователь сначала должен перевести эту фразу на привычную рабочую ситуацию.
Формулировка для приемки: «Менеджер создает договор на 600 000 рублей и отправляет его на согласование. После отправки у руководителя отдела появляется задача по этому договору. У менеджера договор остается в ожидании решения руководителя».
Следом можно пройти второй сценарий с договором на 400 000 рублей и убедиться, что руководитель в согласование уже не включается. Два простых примера показывают правило гораздо лучше, чем одна техническая формулировка.
Сценарии лучше подготовить до встречи
Если приемка проходит в формате «сейчас откроем систему и посмотрим», встреча очень быстро уходит в сторону. Пользователь вспоминает соседнюю проблему, кто-то начинает обсуждать внешний вид формы, появляется новая идея, а один из основных сценариев в итоге вообще забывают проверить.
Подготовленный список дает нормальный каркас: сначала пройти то, ради чего собрались, а новые пожелания записать отдельно и вернуться к ним позже. При этом список не должен быть жестким сценарием демонстрации, от которого нельзя отступать. Если во время проверки обнаружилась реальная проблема, ее, конечно, нужно разобрать.
Кто должен готовить сценарии
Если за требования отвечает аналитик, логично, чтобы основу пользовательской приемки готовил он же. Он знает, какой результат согласовывался с бизнесом и где находятся самые спорные места. Разработчик может добавить случаи, связанные с особенностями реализации, тестировщик - важные пограничные варианты, а пользователь помогает проверить, похожи ли примеры на его реальную работу.
На крупных задачах несколько основных сценариев полезно согласовать еще до разработки. Иногда уже при чтении простого примера выясняется, что бизнес представлял себе результат иначе, и это намного дешевле обнаружить до написания кода.
Перед приемкой я бы проверила не форму документа, а сам сценарий
Мне здесь важнее не количество заполненных колонок, а сможет ли человек пройти проверку без постоянных пояснений со стороны аналитика. Для этого достаточно нескольких вопросов:
- понятно ли из названия, какую рабочую ситуацию проверяют;
- указано ли, кто выполняет действия и с какими исходными данными;
- можно ли пройти шаги без знания внутреннего устройства системы;
- понятно ли, на что именно нужно смотреть;
- описан ли конкретный результат, который можно увидеть;
- не пытаемся ли одним сценарием принять сразу несколько разных изменений;
- включены ли ошибки, с которыми пользователь действительно может столкнуться;
- совпадают ли названия кнопок, статусов и объектов с тем, что человек увидит в системе.
Если на половину пунктов приходится отвечать «ну, я на встрече объясню», сценарий лучше поправить заранее.
После приемки должно остаться чуть больше, чем «все ок»
Через несколько месяцев фраза «заказчик все принял» помогает мало, если непонятно, что именно ему показывали. Поэтому рядом с задачей полезно оставить список пройденных сценариев и отметить, кто подтвердил результат. Для небольшой доработки этого вполне достаточно в комментарии, для крупного блока можно оформить отдельный протокол, если такой порядок уже принят на проекте.
Это полезно не только на случай спора. Если позже в процесс вносят еще одно изменение, по старым сценариям сразу видно, какое поведение было согласовано раньше и что теперь должно измениться.
Приемка нужна не ради галочки
Хорошая пользовательская приемка выглядит довольно просто: человек узнает в сценарии свою работу, выполняет понятные действия, видит результат и может сказать, подходит он ему или нет. Если аналитику приходится половину встречи переводить собственный документ с технического языка на обычный, значит документ изначально писался не для того читателя.
Когда сценарии сформулированы человеческим языком, бизнес начинает не просто кивать, а действительно проверять. Тогда раньше всплывают неправильный согласующий, странное поведение после отказа, недостающий показатель в отчете или лишнее ограничение для пользователя. Именно ради этого приемка и проводится.