Прежде чем взяться за работу над user story, очень важно определить для себя критерии приемки. Это можно сделать, когда вы детализируете бэклог или планируете ближайший спринт. Некоторые команды для этого проводят специальные встречи, которые называются 3 Амиго (подробнее о них в прошлой статье), митинги, kick-off по спецификации или встречи-исследования.
Как не назови, большинству команд это дается с трудом. Главная сложность в том, что такие встречи неструктурированы, а их результат непонятен. Они отнимают много времени и попросту скучные. В итоге, сессии становятся нерегулярными или от них совсем отказываются.
Но есть простой способ сделать такие встречи короткими и очень продуктивными. И называется этот способ Example Mapping или составление карт тест-кейсов.
Как это работает
Конкретные тест-кейсы (примеры) — это отличный способ исследовать предметную область. Они могут стать хорошей основой для ваших приемочных тестов. Когда мы обсуждаем тест-кейсы, всплывают и другие аспекты, которые тоже нужно проговаривать.
- Правила, которые обобщают разные кейсы или наоборот ограничивают области применимости тест-кейса.
- Вопросы о сценариях, когда никто не знает, что на самом деле верно. Или гипотезы, которые мы выдвигаем, чтобы хоть как-то продвинуться в проработке требований.
- Новые user story, которые обнаружились в процессе обсуждения.
В Example Mapping используется набор карточек четырех разных цветов и шариковые ручки, чтобы по ходу разговора записывать новую информацию. Во время встречи информация фиксируется на карточках и размещается на доске, как на картинке выше.
Для начала на желтом стикере нужно записать саму историю и поместить в верхнюю часть доски. Далее, на синих стикерах указываем каждый из критериев приемки или правил, которые у нас выработались ранее. Синие карточки размещаем под желтой.
Каждое правило обычно можно проиллюстрировать несколькими тест-кейсами. Для каждого тест-кейса свой зеленый стикер, который помещается под соответствующее правило.
Пока составляем карту и обсуждаем кейсы, могут возникнуть вопросы, на которые никто из присутствующих не может ответить. Их фиксируем на красных стикерах и продолжаем обсуждение.
Встреча продолжается до тех пор, пока все не убедятся в том, что история полностью понятна, или кончится выделенное на неё время.
Мгновенная обратная связь
В процессе такого разговора легко и быстро строится визуальное представление о текущем понимании истории.
- Доска, покрытая красными стикерами (вопросы), говорит, что еще многое предстоит выяснить.
- Доска, покрытая синими стикерами (правила), указывает на то, что история большая и сложная. Возможно, нужно её декомпозировать. Может быть, нужно взять еще один желтый стикер (истории) и поместить часть историй в бэклог.
- Если у правила слишком много тест-кейсов, то возможно оно слишком сложное, и нужно выделить несколько правил, которые можно детальнее описать отдельно.
Может обнаружиться, что некоторые правила настолько очевидны, что для них не нужны тест-кейсы. Например, если все понимают правило одинаково, то не нужно тратить время и вымучивать фиксированное количество тест-кейсов.
Думать за ограниченное время
Группа из нескольких амиго должна составлять понятную историю приличного размера примерно за 25 минут.
Если у вас не получается уложиться в выделенное время, то возможно несколько вариантов:
- вы еще учитесь использовать этот метод (это нормально);
- у вас слишком большая история (это уже определенно не хорошо);
- в вашей истории слишком много неопределенности.
Что можно сделать? Либо попробовать разделить историю на несколько, либо дать владельцу продукта домашнее задание, чтобы позже вы вместе вернулись к это истории на следующей сессии по example mapping, но уже с ответами.
Matt Wynne из Cucumber предлагает участникам встречи через 25 минут проголосовать, готова ли история для передачи в разработку. Даже если некоторые вопросы остались нерешенными, команда может принять решение, что неопределенности не так много, и ее можно дорабатывать по ходу дела.
Выгода
Example mapping помогает сменить масштаб и сосредоточиться на мельчайших фрагментах поведения истории. Составляя карту, можно выделить правила, найти суть желаемого поведения, а остальное отложить на потом. Из-за такой тщательности исследования example mapping действует как фильтр, не давая большим жирным историям попасть в спринт, чтобы потом преподнести неприятные сюрпризы в последнюю минуту. К тому же этот подход экономит время и помогает поддерживать вовлеченность в процесс заинтересованных людей.
Некоторым кажется, что 3 амиго должны написать приемочные тесты во время этой встречи (например сценарии для Cucumber). В принципе, в некоторых случаях это может иметь смысл, но чаще такой подход будет только отвлекать от истинной цели разговора.
Понятно, откуда берется такое мнение: очевидная цель состоит в том, чтобы взять user story, у которой уже есть некоторые заранее определенные критерии приемки, и найти тест-кейсы, которые можно превратить в приемочные тесты.
Настоящая же цель в том, чтобы достичь общего понимания того, что нужно для создания истории. Можно быстро двигаться к это цели и без высоких технологий.
Упрощайте запись
Поэтому вместо того, чтобы использовать формальные сценарии Gherkin, просто попробуйте быстро собрать список тест-кейсов, используя соглашение об именовании.
Например:
- там, где клиент забыл свою квитанцию;
- там, где продукт был куплен 15 дней назад.
Когда за таким названием кейса скрывается неопределенность, вам инстинктивно хочется конкретики и деталей. Но даже тогда не обязательно придерживаться жесткой структуры Given When Then.
Если результат («тогда») неясен, пример не получится, зато получится вопрос.
Известные неизвестные
Если разговор начинает идти по кругу, значит информации недостаточно. Возможно, на встрече нет нужного человека, или нужно провести какое-то исследование или воспользоваться Spike.
Вместо того, чтобы выслушивать мнение каждого участника о том, каким с их точки зрения должен быть результат, просто запишите вопрос на красной карточке и двигайтесь дальше. Так неизвестное превратится в известное неизвестное. Это большой прогресс.
По опыту даже этот аспект составления карт примеров может превратить встречи 3-х Амиго из скучных в быстрые и продуктивные.
Кто должен участвовать?
Минимум — это ваши 3 амиго: разработчик, тестировщик и владелец продукта (бизнес-аналитик). Это всего лишь минимум. Кроме этого, можно пригласить кого-то из эксплуатации, специалиста по UX или еще кого угодно, кто имеет отношение к обсуждаемой истории. Любой, кто может помочь найти новые вопросы или превратить вопросы в ответы во время беседы, будет полезен.
Пока вы осваиваете эту технику, удобно найти кого-то на роль фасилитатора. Его формальная задача будет в том, чтобы все сказанное сразу же записывалось на стикеры. Тест-кейсы и вопросы быстро обсуждаются во время сессии, и требуется дисциплина, чтобы своевременно записывать их на стикерах, чтобы видеть, о чем идет речь.
Итак, когда писать на Gherkin?
Не поймите неправильно, в использовании Gherkin есть огромная ценность, особенно в первые дни проекта, когда вы вырабатываете общий язык. Жизненно важно, чтобы сценарии были выражены так, чтобы все в команде верили им.
Но для описания тест-кейсов таким образом требуется иной способ . Нужно не просто решить, какие кейсы попадают в рассматриваемую область, и установить для них общие правила.
Для команды, которая работает с достаточно зрелым доменным языком, владельцу продукта выгоднее тратить свое время и энергию на составление карт, а задачу написания Gherkin оставить двум другим амиго. После того, как они разработают спецификацию Gherkin, владелец продукта сможет дать фидбек. Задавая себе вопрос: «Я бы так написал?» можно проверить, насколько эффективным было составление карты с точки зрения передачи знаний о продукте своим амиго.
Как часто это делать?
На практике рекомендуется встречаться через день. Просто выберите одну user story и уделите ей 25 минут внимания, а затем возвращайтесь к работе. Если попытаетесь сделать больше, только зря потратите энергию.
Но у меня распределенная команда!
Для этого уже придумали решения, например, списки стикеров в Google keep или онлайн-доски с цветными стикерами. Можно использовать mind-map. Главное, чтобы вам было просто и быстро работать, чтобы вы могли сосредоточиться на разговоре.
Несколько заключительных советов
Важно четко различать правила и тест-кейсы, прежде чем использовать example mapping. Для этого есть забавное упражнение.
Помните, конечная цель такой встречи — обнаружить то, что вы еще не знаете. Глупых вопросов не бывает, все они помогают по-настоящему исследовать проблему.
Работая по этой методике вы обнаружите, что правила создают естественные линии развития вашей истории. Постарайтесь спокойно относится к вопросам, разделяйте их и откладывайте в сторону. Тогда сможете сосредоточиться на решении основной проблемы. Усложнить и довести до идеала можно и позже.
О практике 3 Амиго для проработки требований и построении карт тест-кейсов мы будем говорить на конференции QualityConf. Кроме того, в списке принятых докладов есть и другие крайне интересные практические подходы для создания качественного IT-продукта. Конференция QualityConf впервые пройдет в рамках фестиваля РИТ++ 27 и 28 мая, успевайте присоединиться.
Автор: Travieso
