BRIEF-принципы

Чтобы сценарии приёмки приносили команде разработки максимальную пользу, они должны соответствовать BRIEF-принципам. Это значит, что сценарии приёмки:

записаны на бизнес-языке, то есть языке, понятном пользователям (Business language),
содержат реальные данные (Real Data),
раскрывают намерения (Intention Revealing),
содержат только необходимую информацию (Essential),
сфокусированные (Focused),
краткие (Brief).

Принципы называются так, потому что начальные буквы первых пяти из них образуют акроним BRIEF, а название шестого полностью совпадает с ним. Акроним BRIEF придумали Сэб Роуз (Seb Rose) и Гаспар Надь (Gáspár Nagy). Первый — консультант, аналитик и разработчик более чем с 30-летним опытом, второй — тренер по автоматизации тестирования. Вместе Роуз и Надь написали несколько книг о разработке, основанной на поведении ПО (Behavior Driven Development, BDD).

Разберёмся с тем, что такое BRIEF-принципы, на примере истории «Выписка по счёту клиента».

Business language

Поскольку ПО разрабатывается для того, чтобы пользователи решали свои проблемы или использовали возможности, сценарии приёмки должны содержать слова из понятной пользователям предметной области.

Системный аналитик описывает сценарии приёмки на понятном пользователям, простом языке без терминов из области разработки ПО или технических подробностей реализации. Если нужно, системный аналитик может включить в сценарии приёмки профессиональный жаргон, которым владеют пользователи. Благодаря этому:

сотрудничество между пользователями и командой разработки станет эффективнее, потому что обсуждение будет идти на одном языке,
сформируется единое понимание сценариев приёмки,
снизится зависимость сценариев приёмки от технических решений, которые принимаются в процессе реализации.

Почему сценарии приёмки важно писать на языке пользователей

Рассмотрим сценарий приёмки, который написан на языке команды разработки. В нём используются названия запросов, содержащиеся в программном коде. Пользователи не смогут дать качественную обратную связь при обсуждении такого сценария, так как не знают, какие запросы использует программный код.

Пример сценария на языке, понятном только команде разработки

Если позднее запросы будут меняться, такой сценарий приёмки устареет, и системному аналитику придётся править его или писать новый. Обновление сценариев приёмки может затянуться надолго. В итоге вместо того, чтобы сократить время на разработку ПО, сценарии приёмки создадут дополнительную нагрузку на команду, а значит, она потратит больше времени. Чтобы избежать этого, нужно писать сценарий приёмки на языке пользователей.

Пример сценария на бизнес-языке понятном всем заинтересованным лицам

Real Data

Примеры в сценариях должны быть конкретными и основанными на реальных данных. Реальные данные — это данные, которые пользователи могут применить для проверки поведения ПО. Так на ранних этапах процесса разработки ПО можно выявить детали ожидаемого результата и крайние случаи.

Крайний случай (Edge Case) — это проблема или ситуация, которая возникает только при максимальном или минимальном значении переменной. В разработке ПО минимальные и максимальные значения требуют специального алгоритма обработки со стороны ПО. То есть для крайних случаев разработчики должны написать отдельный программный код, а тестировщики — отдельные тесты.

Рассмотрим пример сценария приёмки, который написан с использованием вымышленных данных.

Реальные номера банковских счетов состоят из 20 цифр. В примере используются только четыре цифры вымышленного номера счёта. Прочитав такой сценарий приёмки, команда разработки может неправильно понять, как должно формироваться имя файла. Нужно ли туда включать:

номер счёта целиком,
только четыре первые цифры,
только четыре последние цифры.

Таким образом, в результате реализации истории с этим сценарием приёмки пользователи могут получить файл с разными вариантами названия:

40817810701005643178_04_22.pdf — если название должно включать номер счёта целиком;
4081_04_22.pdf — если название должно включать только первые четыре цифры;
3178_04_22.pdf — если название должно включать только последние четыре цифры.

Но только одно из этих названий будет соответствовать ожиданиям пользователей.

Разработчики и тестировщики могут не учесть, насколько длинными должны быть номера счетов, при разработке хранилища данных и в тестах. Тогда формирование выписки по счёту клиента не будет работать. Чтобы этого избежать, при записи подобного сценария приёмки нужно использовать реальные данные.

Intention revealing

Сценарии приёмки должны объяснять, какой результат ожидается по итогу их реализации, а не механизмы его достижения. У сценариев приёмки должно быть название, которое отражает желаемый результат, а в описании шагов не должно быть названий элементов интерфейса.

Так может выглядеть сценарий приёмки с названиями элементов интерфейса:

В этом сценарии приёмки описаны не только элементы интерфейса, но и то, как клиент с ними взаимодействует. Это описание не помогает команде разработки лучше понять ожидаемый результат от реализации сценария и отвлекает её от намерений клиента. Более того, описание элементов интерфейса ПО в сценариях приёмки ограничивает команду разработки в их реализации, предопределяя, как должен выглядеть элемент интерфейса.

Чтобы сделать намерения клиента более очевидными, нужно сфокусироваться на цели сценария приёмки (она отражена в его названии) и отказаться от описания взаимодействия пользователя с пользовательским интерфейсом.

Essential

Сценарии приёмки должны содержать только ту информацию, которая необходима для объяснения ожидаемого поведения ПО. Если сценарии приёмки, их шаги или слова, которые описывают эти сценарии, не помогают достичь этой цели, их считают несущественными и удаляют.

Сценарий приёмки с несущественной информацией может выглядеть так:

В примере сценарий приёмки, который нужен, чтобы описать выбор счёта для формирования выписки. При этом он содержит информацию о статусе клиента, времени заказа выписки и об операционной системе на устройстве клиента. Эта информация может помешать команде разработки в понимании ожидаемого результата. Её участники могут задуматься, как описанные условия влияют на достижение цели. Тогда они сконцентрируются на обсуждении деталей реализации и потратят время на реализацию ненужных функций.

Чтобы этого не произошло, нужно удалить из сценария приёмки все шаги, которые не относятся к описанию ожидаемого поведения ПО.

Focused

Как и критерии приёмки, сценарии приёмки должны фокусироваться на объяснении только одного примера поведения ПО. Если системному аналитику кажется, что в сценарии нужно описать больше одного примера, тогда ему необходимо создать несколько сценариев приёмки.

Так может выглядеть сценарий приёмки, который описывает несколько примеров поведения ПО:

Этот сценарий приёмки описывает и выбор счёта, и выбор периода для формирования выписки, то есть несколько функций ПО одновременно. Название сценария указывает на то, что команда разработки планирует проверить (функцию выбора счёта). Шаги, необходимые для проверки функции выбора периода, не соответствуют цели сценария, поэтому их нужно выделить в отдельную структуру сценария. Вот так:

Brief

Большинство сценариев приёмки должно укладываться в пять (или меньше) шагов. Сценарии такого размера проще читать, понимать и осмыслять.

Так может выглядеть слишком длинный сценарий приёмки:

Некоторые шаги в примере напрямую не связаны с формированием выписки. Они могут подразумеваться или входить в другие сценарии приёмки (например, в сценарий авторизации клиента в приложении или сценарий просмотра счетов). Шаги, которые напрямую не связаны с заявленной целью сценария, нужно удалить, чтобы не отвлекать команду разработки и пользователей от цели сценария приёмки.

Agile-практики

BRIEF-принципы