Всем привет! Меня зовут Валентина Ляликова. Я ведущий бизнес-аналитик в X5 Tech и преподаватель направления «Пользовательские истории и критерии приёмки» в Школе бизнес-анализа X5 Tech.
Большой опыт работы на разнообразных проектах помог сформировать мне список правил, которых я придерживаюсь каждый день при написании User Story и Acceptance Criteria (US+AC). В этой статье хочу поделиться ими с вами и показать на примерах ошибочных вариантов написания документа US+AC, почему так важно применять эти правила в работе.
Немного теории
User Story (US) – это краткая формулировка того, что мы будем разрабатывать в системе, что привнесёт ценность в пользовательский опыт (решит его проблему).
US формулируются по такому шаблону:
Я как персона/пользователь системы
ХОЧУ желание/потребность/функциональность
ЧТОБЫ получить ценность/решить проблему
Однако, не всегда одного текста US достаточно. Поэтому для того, чтобы разработчик понял, что нужно сделать, а тестировщик смог проверить результат, в дополнении к User Story пишутся критерии приёмки.
Критерии приёмки или Acceptance Сriteria (AC) – это структурированные, подробные пункты требований к создаваемой системе, которым должна соответствовать User Story, чтобы работа по ней считалась завершённой с точки зрения клиента / владельца продукта.
Идеальные критерии приёмки:
Бинарные
Полные
Подтверждаемые
Однозначные
Непротиворечивые
А также все AC совместно с US должны удовлетворять критериям INVEST:
Independent – независимая,
Negotiable – обсуждаемая,
Valuable – ценная,
Estimable – возможная для оценки,
Small – компактная
Testable – тестируемая.
Теперь правила, которые мне помогают в написании критериев приёмки. Для себя я их сформулировала так:
Используй опорный критерий
Структурируй
Пиши и сокращай
Помни о правилах INVEST и хороших AC
Перечитай сам и дай другу
Используй лайфхаки
Приступим к разбору каждого правила на рабочих примерах.
Правило №1: Используй опорный критерий
Если абстрагироваться от теории, то US + AC – это та же самая статья, в начале которой описывается краткая суть, краткое содержание того, чем вы хотите поделиться с читателем. Любому потребителю вашего документа важно однозначно понимать краткое содержание описываемого функционала. Это и есть опорный критерий.
Давайте разберём важность применения этого правила на примере следующей
User Story, описывающей функциональность отображения списка доступных ресторанов и магазинов в мобильном приложении доставки еды:
Как выглядят критерии приёмки без опорного критерия:
Теперь посмотрим на критерии приёмки с опорным критерием:
Как мы видим, опорный критерий помогает нам достичь однозначности и определённости. Мы сразу понимаем, что на главной странице есть функциональность отображения списка магазинов и ресторанов, а также у пользователя есть возможность поиска для сокращения времени на выбор позиций для покупки. Да, это другая User Story, но мы обозначаем, что она есть, т. к. эта функциональность напрямую помогает работать пользователю со списком ресторанов/магазинов.
Правило №2: Структурируй
Мы всегда должны понимать, кем и как используется наш документ. В нашей команде тестировщик использует US + AC для составления тест-кейсов, разработчик – для написания кода будущего функционала, а также в качестве критериев Definition Of Done после написания кода.
Если игнорировать структуры в написании, это может привести к ошибкам в написании тест-кейсов и багам в созданной функциональности.
Рассмотрим пример написания критериев приёмки без структуры и с ней. User Story описывает функциональность онбординга (инструкции использования) пользователя в мобильном приложении «Профиль клиента».
User Story:
Как выглядят критерии приёмки без структуры:
Пользователь авторизовался первый раз в мобильном приложении. После отображается «Онбординг». Онбординг состоит из нескольких страниц, каждая из которых состоит из: блока основной информации, кнопок навигации по онборингу.
Блок основной информации на странице 1 содержит информацию об управлении профиля, на странице 2 – информацию о возможности подключения сервисов, на странице 3 – информацию о способах оплаты, на странице 4 – об обращении в службу поддержки. Подробное описание основной информации всех страниц смотри на Макетах
кнопки навигации: на 1, 2, 3 страницах отображается кнопка «Вперёд», нажимая на которую, открывается следующая страница. На 2, 3, 4 страницах отображается кнопка «Назад», нажимая на которую, открывается предыдущая страница. На странице 4 отображается кнопка «Готово», нажимая на которую» открывается Главная страница мобильного приложения. Если пользователь авторизуется в МП не в первый раз, то онбординг не открывается, открывается сразу главная страница мобильного приложения.
Как выглядят структурированные критерии приёмки:
Согласитесь, что читать и понимать второй вариант гораздо приятнее. Структурировать критерии приёмки в виде таблицы и писать текст критерия по пунктам помогает читателю не запутаться. Тестировщику, в свою очередь, будет легко связать первый критерий приёмки с первым тест-кейсом, а разработчику – с текстом кода. Структура также помогает авторам не запутаться в своём документе, так как в нём чётко видно, какие критерии уже успели описать, чего не хватает, не упущена ли какая-то логика.
Критерии желательно располагать в порядке основного сценария использования функциональности, т. е. не сначала написать про кнопки, а потом про первое отображение, иначе не понятно будет, к чему кнопки относятся. Кроме этого, можно каждый критерий сделать в виде гиперссылки и тогда будет удобно ссылаться на него в следующих документах.
Правило №3: Пиши и сокращай
Если вы ещё не читали книгу «Пиши и сокращай» Максима Ильяхова, то советую вам это сделать.
Приведу пример, который мы разбирали с учениками в нашей Школе бизнес-анализа.
User Story:
Один из критериев выглядел так:
Согласитесь, есть неоднозначность и путаница при чтении этого критерия? А ещё в нём много «воды». Например, что автор хотел сказать предложением «Сегментация пользователей будет осуществляться на уровне кода»? Могу только догадываться, что он имел в виду, что сегментация будет импортироваться из другой системы, о чём он говорит во втором предложении. То есть первое предложение бессмысленно.
А последующие предложения содержат в себе несколько критериев, которые достаточно трудно вычленить, если читаешь их в таком виде.
Как можно было бы переписать этот критерий:
Очевидно, что чем меньше слов, тем больше мы получаем нужной и понятной информации, которую удобно обрабатывать любому потребителю документа.
Правило №4: Помни про INVEST и о критериях хороших AC
Здесь я не буду приводить примеры. Правило заключается лишь в том, что после написания всех критериев необходимо перечитать весь текст на предмет выполнения INVEST’а (о нём я говорила в начале статьи).
Да, часто бывает так, что какой-то из критериев не выполняется (как правило, это независимость от других US). Но важно это обсудить с командой и принять общее решение – разрабатывать задачу с учётом этих рисков или нет.
О критериях хороших AC я также говорила в самом начале статьи (бинарность, полнота, подтверждаемость, однозначность, непротиворечивость).
Что касается инструкций, я также, как и с критериями INVEST, прохожусь по всем критериям приёмки и проверяю их на соблюдение каждого «критерия хороших AC».
Правило №5: Перечитай сам и дай прочитать другому
Делитесь документом с коллегами. В моей команде, прежде чем отдать документ разработчикам, я прошу проверить его на адекватность владельца продукта, тестировщика и системного аналитика. Вы – часть команды. А ответственность за результат лежит на всех её участниках. Поэтому не бойтесь делиться и принимать комментарии и замечания от коллег. Помните, что принятие обратной связи – это шаг вперёд в развитии вашей компетенции, а также в развитии вашего проекта/продукта. Ну и элементарно: мнение со стороны помогает ничего не упустить и быть правильно понятым.
Правило №6: Используй лайфхаки
И последний пункт, которым я хотела поделиться – это лайфхаки. Для облегчения формирования критериев приёмки вам могут помочь следующие шаблоны написания:
Если вам необходимо описать, ЧТО происходит в системе в результате какого-либо события, то используйте принцип: ЕСЛИ произошло событие (если пользователь нажал на кнопку), ТО получаем результат (ТО система сохраняет данные в системе).
Также можно вместо ЕСЛИ, ТО описать событие и выделить результат фразой «В РЕЗУЛЬТАТЕ». Эти конструкции помогут не наплодить несколько критериев в одном:
Общеизвестный формат описания Given When Then (по Геркину). Он похож на формат ЕСЛИ, ТО, только здесь ещё прописывается состояние системы в начальный момент.
В блоке ДАНО пишем состояние системы в начальный момент, в блоке КОГДА – действия пользователя, событие, и в ТОГДА – результат:
Если вам необходимо описать атрибуты и перечислить из чего состоит, например, какое-то меню, то обозначаем, что на экране отображаются следующие правила и перечисляем каждое из них отдельным пунктом:
Если критерий большой, то используйте для описания вложенные таблицы и выделяйте примеры, характерные для критерия, чуть ниже основного текста критерия приёмки:
Заключение
Я очень надеюсь, что список правил и лайфхаки, которые я вывела в ходе своей многолетней практики, помогут вам усовершенствовать ваши требования.
Делитесь в комментариях, каких правил и лайфхаков вы придерживаетесь при написании US + AC. Очень интересно узнать ваш опыт и использовать его на практике!
