Использование BDD в разработке и тестировании
Начальный этап любого проекта это сбор требований. От качества требований зависит качество продукта, полученного в результате разработки. Одна из задач этапа - сформировать единое видение на результат и исключить потерю информации при передаче между участниками проекта. Тем самым обеспечить высокое качество создаваемой системы.
За период существования отрасли придумано множество способов и подходов, которые позволяют решить эту проблему. Один из подходов это BDD - Behaviour Driven Development. Идея достаточно простая - описать требования в виде сценариев, которые cмогут использовать все участники проекта на всех этапах проекта. BDD отлично подходит для разработки многопользовательских систем со сложной бизнес-логикой. Пройдем весь путь от бизнес-требования до автоматизированного теста и применим подход.
Чтобы BDD работал на практике, все участники проекта должны владеть языком сценариев. На проектах с ограниченными сроками, невозможна выработка "с нуля" подобного общего языка между заказчиком и исполнителем. Все осложняется еще тем, что адаптация Gerkin для русского языка, звучит чужеродно и неестественно. Специалист, который никогда не работал со сценариями, будет сопротивляться новому для него языку.
Поэтому как правило заказчики пишут требования в классическом формате и согласовывают их. Далее команда разработки должна перевести требования в сценарии нужного формата. Если нет никакой связи между требованиями и сценариями, то при изменении требований актуализировать сценарии можно только вручную.
Еще один важный момент это команда должна не только понимать основы BDD, но и уметь его применять. На практике когда под новый проект собирают новую команду она также не может полноценно использовать методологию. Если сценарии могут разрабатывать только ключевые сотрудники, то очень быстро применение методики сходит на нет, а сценарии становятся неактуальными.
Выходом из ситуации может быть еще одно упрощение методологии. А именно выделение критичных сценариев, их формализация, описание и дальнейшая автоматизация.
Согласно методики BDD сценарий разрабатывается до того, как будет готова какая-либо реализация системы. Поэтому сценарий не содержит описание реализации. Получаем еще одну проблему - переход от общего сценария с бизнес-целями к конкретным действиям в системе, которые реализуют этот сценарий. Например, бизнес-цель может достигаться в системе различными способами. Получается, что аналитик должен держать в голове реализацию и учитывать ее при разработке сценариев, что невозможно для несуществующего функционала и новой для исполнителя предметной области. Решением является последовательная детализация общего сценария до такого уровня, когда он может быть выполнен в системе. При этом кроме описания шагов, приводящих пользователя к одной цели, в сценарии должно быть описание тестовых данные, которые отражают специфику каждого сценария.
В результате от методологии BDD остались только сценарии, написанные на языке Gherkin. При этом сценарии слабо связаны с исходными требованиями, а заказчики про эти сценарии ничего не знают. При изменении требований команда должна находить нужные сценарии и актуализировать их. Сценарии создаются когда система уже разработана и готова к тестированию, используются только для автоматизации тестирования.
В итоге дошли до автоматизации сценария. Разработчик, используя соответствующий инструментарий, превращает пользовательский сценарий в набор исполняемого кода. Разрабатываются так называемы "снипеты". В итоге получается двухуровневая архитектура "текстовый сценарий-программный код", с соответствующими сложностями при поддержке такой конструкции. Специалист без технических навыков не сможет самостоятельно поддерживать и развивать такое решение.