Вы когда-нибудь слышали о трех С пользовательских историй? Возможно, есть смысл освежить в памяти три ключевых аспекта, используемых при написании пользовательских историй. Итак: Карточка (Card), Подтверждение (Confirmation), Диалог (Conversation).
Какой из этих аспектов является наиболее важным – это вопрос, который по сегодняшний день остается спорным. Часто на занятиях я упоминаю о том, что наиболее весомым аспектом можно считать последний – Диалог. Но, откровенно говоря, сделать выбор в пользу именно этого аспекта я смог лишь в результате кропотливого труда.
В данной статье мне бы хотелось уделить внимание области, которая часто упускается из виду. Я имею в виду пункт Подтверждение. Иногда данный аспект также определяют как:
- Приемочные критерии;
- Приемочные тесты;
- Мини-UAT для каждой истории;
- Тесты подтверждения.
Однако чаще всего можно встретить термин «приемочные тесты». Например, затрагивая термин ATDD, который обозначает разработку, основанную на тестах уровня приложения, которая может сыграть роль мощного «побочного эффекта» по мере того, как вы приближаетесь к написанию пользовательских историй.
Итак, давайте начнем с вводного примера.
Вот то, что я бы назвал «Эпиком» с некоторыми дополнительными эпиками, полученными из него. У нас пока нет приемочных тестов, но мы начинаем разрабатывать набор пользовательских историй уровня эпиков.
- Как писателю, мне бы хотелось добавить возможность изменения шрифта; 20-30 различных типов шрифтов и цветов, чтобы я мог выделить различные уровни взаимодействия с моими читателями.
- …добавить возможность добавления различных атрибутов: подчеркивание, преобразование шрифта в жирный и курсив, подстрочные и надстрочные индексы и т.д.
- Добавить форму для создания заголовков; 3 основных уровня.
- Добавить возможность добавления отступов.
- Добавить возможность создания списков (нумерованных и маркированных); для начала одноуровневых, затем перейти к многоуровневым.
- Добавить возможность выравнивания текста: по левой или правой стороне, по центру, попеременно.
- Добавить возможность отмены последних действий при редактировании текста.
- Создать модель абзаца (либо несколько моделей).
- Добавить возможность показывать либо скрывать значки форматирования.
- Установить обозначение для «style set», которое может использоваться для создания коллекции избранного.
Давайте остановимся на данном Эпике:
Как писателю, мне бы хотелось добавить возможность изменения шрифта; 20-30 различных типов шрифтов и цветов, чтобы я мог выделить различные уровни взаимодействия с моими читателями.
Мы начнем писать приемочные тесты для этой пользовательской истории. Для написания приемочных тестов я предпочитаю использовать шаблон «Убедиться, что…». Итак:
- Убедиться, что подчеркивание текста работает.
- Убедиться, что выделение жирным шрифтом работает для всех типов и цветов шрифта.
- Убедиться, что работают все возможные комбинации атрибутов.
- Убедиться, что при изменении размера шрифта атрибуты не изменяются.
- Убедиться, что границы абзаца не затрагиваются при изменении атрибутов.
- Убедиться, что атрибуты также применяются к элементам, стоящим до и после основного текста; например, убедиться, что при выделении нумерованного списка жирным шрифтом цифры также выделяются.
В данном случае вы заметите, что все приемочные критерии функционально ориентированы. Это не обязательно плохо, однако было бы неплохо также добавить несколько основных вариантов возможных ошибок. Например, допустим, что добавление подстрочных и надстрочных индексов по какой-либо причине недоступно для хедеров и футеров. В таком случае необходимо добавить в список следующие критерии:
7. Убедиться, что подстрочные и надстрочные индексы доступны для хедеров и футеров и что сообщение об ошибке отображается в режиме онлайн на консоли ошибок.
Я думаю, вы заметили значимость и ясность приемочных тестов для пользовательских историй. Я всегда обращаюсь к ним, когда говорю о трех важных точках зрения, которые играют определяющую роль при работе с пользовательскими историями:
- С точки зрения разработки: в историях должны быть конкретные идеи, которые дают разработчикам возможность понять, для чего нужна та или иная опция с точки зрения бизнеса. Заказчики должны делиться и некоторыми нефункциональными требованиями, например, требованиями к производительности.
- С точки зрения тестирования: они должны содержать некоторые «как» и «почему», которые стоят за пользователями и их намерениями. Тестировщики должны использовать данную информацию для того, чтобы создать серию тестов, которые заостряют внимание на наиболее важных элементах, окружающих ценность для пользователя.
- С точки зрения владельца продукта: пользовательские истории – это важный канал коммуникации, который связан с Карточкой (помните 3С – важнейшие аспекты пользовательских историй?). Обычно владельцы продукта пишут карточки во время консультации с командой – поэтому требования выявляются и проверяются коллективно. Такие карточки служат своего рода контрольным перечнем приемки.
Такое сочетание ролей (перспектив), которые окружают приемочные критерии, помогает обеспечить удовлетворение всех требований клиента и получить богатый набор пунктов для тестирования.
Автор: Robert Galen
Перевод подготовила Екатерина Зданевич
Оригинальная статья
P.S. Если вы недавно прочитали классную статью по бизнес-анализу и считаете, что ее стоит перевести, дайте нам знать, например, поделившись ссылкой в комментариях.
