Введение

Здравствуйте! Меня зовут Алина, и я хочу с вами поделиться своим опытом проведения BDDSM-практик. Мой Господин принудил меня к этому. Было немножко больно, но потом очень приятно.

Для начала давайте разберёмся в терминах. BDDSM — это Behavior Driven Development and Story Mapping, а не то, что вы, шалунишки, подумали. Термин родился в ходе обсуждения командой 1Service инструмента StoryMapper в рамках проектирования знаменитого (в узких кругах) программного продукта Checkушка.

Методика BDDSM может применяться как для разработки нового функционала (классика), так и для организации регрессионого тестирования legacy-систем (ана… ну вы поняли).

Методика подразумевает выполнение следующей последовательности шагов:

1. Разработка карты пользовательских историй
2. Составление критериев приёмки пользовательских историй (с примерами!)
3. Написание сценариев с шагами первого уровня (под каждый критерий приёмки)
4. Написание шагов второго уровня (с использованием библиотечных шагов Vanessa Automation, она же VA)
5. Вынесение шагов второго уровня в экспортные сценарии (чтобы не загромождать основные сценарии)
6. Мониторинг результатов выполнения сценариев в Checkушка (ну собственно то, ради чего)

А теперь по каждому из этих шагов подробнее.

Разработка карты пользовательских историй

Почему это первый шаг? Потому что карта пользовательских историй — это инструмент визуальной структуризации хаоса пользовательских требований. Когда требования не структурированы, с ними очень тяжело работать, трассировать, отслеживать зависимости, и в результате понимать, какой блок функционала проблемный, а какой нет. Конечно, существуют и другие методы структурирования информации, но поскольку парадигма BDD — это порождение экосистемы Agile, то вполне логично использовать соответствующий инструментарий (Story Mapping). Это приемлемо как для задач разработки нового функционала, так и для проверки регресса legacy-систем. В первом случае Story Map порождается в ходе мозгового штурма на начальном этапе каждой итерации разработки, во втором — как результат интервьюирования пользователей legacy-системы. Для желающих прикоснуться к тайнам искусства SM предлагаю следующий состав первоисточников ([1], [2]).

Следующий вопрос — это правила структурирования. Поскольку мы на территории Agile, то эти самые правила гибкие до невозможности. Например, существуют такие распространённые вариации (из [1]):

1. Goal→Activity/Feature→Task/Epic→User Story
2. User→Goal→Journey→Activity→Story
3. NFR(non-functional requirement)→Requirement→Story

В инструменте StoryMapper используется следующая иерархия: Usage Flow→User Activity→User Story. Usage Flow — это некий поток бизнес-ценности в рамках предприятия (как вариант: направление деятельности, подразделение предприятия, цепочка поставки ценности, бизнес-процесс). В рамках этого потока существует разнообразная пользовательская активность, которая расшифровывается конкретными пользовательскими историями, реализующими эту активность.

Это была теория, теперь, собственно, практика. В качестве примера рассмотрим разработку функционала по автоматизации процессов предприятия в рамках направления деятельности "Электронная коммерция".

Я созванивалась с ИТ-директором заказчика, и он мне рассказал свою грустную историю своё видение нового направления деятельности его предприятия. В рамках этого направления: каталог товаров выгружается на сайт, довольные клиенты заказывают эти товары на сайте (за рамками системы), заказы с сайта загружаются в учётную систему. После этого ответственный работник изучает хватает ли на предприятии товаров под этот заказ и обеспечивает его товарами (с центрального склада и магазинов). Когда товары приезжают, кладовщик группирует их под каждый заказ. Когда приезжает машина службы доставки, кладовщик печатает этикетки и сопроводительные документы и передаёт заказы службе доставки. По мере доставки товаров клиентам, учётная система службы доставки меняет статусы заказов и товаров, система получая эти статусы либо фиксирует факт продажи, либо формирует возврат товаров. После того, как цикл доставки завершён, служба доставки присылает информацию об оплате с разбивкой по каждому заказу — и в системе должны сформироваться документы по корректировке задолженности. По ходу общения я составляла карту активностей в рамках UF "Ecom", и вот что получилось:

Я продолжила разговор. В результате мы выяснили, что UA195 и UA196 — это типовой функционал модуля обмена с сайтом, про него пока думать не нужно, будем считать, что он заработает "из коробки". По поводу UA279 мне сказали, что здесь достаточно будет построить отчёт с информацией о наличии товаров из заказа на всех складах предприятия, заказы на перемещение и сами перемещения менеджер и кладовщик будут формировать вручную. UA286 подразумевает, что когда товары будут перемещены на склад электронной коммерции, то они должны автоматически зарезервироваться под соответствующие заказы, без необходимости заходить в каждый из них. UA289 оказался проще, чем казался: заказчик не хотел, чтобы сборка под заказ проходила через сканирование штрихкодов, поскольку товары и так сканировали при приёмке на склад, соответственно, достаточно просто указать в заказе признак его собранности. Конечно, по мере роста количества заказов — всё может поменяться, но пока так. Кроме того, по факту сбора товаров необходимо распечатать и наклеить этикетки и сборочные листы по шаблону службы доставки, а также ТОРГ-12 или УПД. В рамках UA296 необходимо под каждый заказ, передаваемый службе доставки, сформировать пакет документов учётной системы, так, чтобы можно было учитывать какие товары сейчас находятся у службы доставки. Кроме того, необходимо распечатать ТТН по всем заказам, которые передаются водителю. UA303 подразумевает, что у службы доставки есть API (веб-сервис) и нужно организовать его периодический опрос с целью уточнения состояния доставки наших товары. Если товары отгружены клиенту, то необходимо сформировать документ отгрузки. Если клиент отказался от товаров, то надо отработать возврат товаров на склад хранения. И вот получилась такая карта пользовательских историй:

Составление критериев приёмки пользовательских историй

Следующий шаг находится на стыке SM и BDD. С одной стороны, критерии приёмки (acceptance criteria) — это инструмент конкретизации пользовательской истории, когда мы фиксируем ключевые моменты, которые важны заказчику при реализации данной пользовательской истории, с другой стороны (и это надо чётко осознавать!), критерии приёмки — это будущие сценарии приёмочного тестирования. В начальном своём виде критерии приёмки — это некий чеклист, каждый пункт которого озвучивается заказчиком, то есть он их просто называет: "вы когда будете делать учтите вот этот момент, и ещё очень важно чтобы было вот так-то, и обязательно чтобы не было возможности сделать", а я их просто записываю . Если заказчик не готов сходу формулировать критерии приёмки, то я его подбадриваю вопросом: "А как вы будете проверять, что мы вам всё сделали правильно?".

Далее, при более детальной проработке я требую от заказчика примеры (а то и несколько) на каждый критерий приёмки. Почему так? Потому что критерии приёмки должны быть чёткие и конкретные, иначе они не нужны — ни программист не поймёт как это делать (и по статистике общения с программистами начнёт экспериментировать с юзабилити), ни тестировщик не поймёт как это тестировать и тоже начнёт сочинять тест-кейсы. То есть плюсы в чём, когда заказчик участвует в составлении примера для критерия приёмки — он, с одной стороны, подписывается, что именно так и надо делать и проверять, а с другой — если пример показывает убогость решения — может пересмотреть сам критерий приёмки, либо сформулировать какой-то дополнительный. Подробнее у Аджича в Specification By Example [3].

Теперь о том, как зафиксировать критерии приёмки в StoryMapper. Как вы, наверное, уже успели заметить, все объекты, создаваемые в StoryMapper — это feature-файлы (всё в рамках концепции "документация — это код"). Стало быть вы вольны записывать критерии приёмки в свободной форме. Например, немногие из тех, кто пишет фичи в курсе, что в рамках синтаксиса Gherkin, можно писать свободный текст после блока "Функция/Функционал" или после блока "Сценарий" вплоть до ближайшего ключевого слова, написанного с начала строки: