BDD подход - новый взгляд на известные практики

В последние годы BDD (Behaviour Driven Development — «Разработка через поведение») приобретает все большую популярность. Благодаря развитию DevOps технологий и вниманию к CI/CD процессу интерес к BDD неуклонно нарастает. В то же время многие считают BDD всего лишь нотацией, используемой при автоматизации тестирования, и нередко даже матерые тестировщики не видят разницы между BDD и TDD (Test Driven Development — "Разработка через тестирование") методологиями. А ведь ни в названии, ни в определении BDD тестирование не упоминается.

В википедии BDD определяется как процесс. Процесс, который призван содействовать улучшению сотрудничества заинтересованных лиц, участвующих в создании программного обеспечения как с технической, так и нетехнической стороны. Цель этого процесса - выработать единое понимание поведения приложения. Именно эта формулировка отражена в названии и определяет основное предназначение подхода.

Согласно такой дефиниции BDD имеет такое же отношение к тестированию как и другим фазам разработки.

Исторически BDD действительно является продолжением TDD методологии, предлагая основывать разработку на сценариях приемочного тестирования. Однако, не менее важная его составляющая - привнесенная из DDD (Domain Driven Design — Предметно-ориентированное проектирование) концепция DSL ( Domain-Specific Language - специфичный предметно-ориентированный язык) - естественного языка, понятного всем участникам процесса и позволяющего объединить постановку задачи, тесты и документацию воедино.

Основоположники подхода не раз подчеркивали, что рассматривают BDD, в первую очередь, как средство улучшение коммуникаций между командой разработки и бизнесом. Дэн Норт (Dan North) говорил о BDD как о расширении практик TDD от использования внутри среды разработчиков до применения в качестве единого языка общения всех стейкхолдеров проекта и делал акцент на расшифровке последнего D как development: end-to-end software development.

Собственно в этой глобализации видятся перспективы этой методологии, и одновременно кроется ее основная проблема. Применение BDD не ограничивается использованием новых технологических средств, но влечет изменения подходов, образа мышления и даже корпоративной культуры. Оно может быть успешным только при условии вовлеченности всех заинтересованных лиц. Внедрение BDD бросает вызов всем причастным к разработке и, в частности, аналитикам. Именно от аналитика ожидается весомый вклад в создание языка описания функциональности, понятного каждому участнику. Ведь именно аналитик является связующим звеном между бизнесом и разработкой. При этом фокус его деятельности смещается от передачи информации в сторону налаживания взаимодействия. Согласно емкому образу, который использовали Dan North и Martin Fowler, аналитик выступает скорее в роли строителя мостов, а не лодочника.

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

Еще одной техникой, неразрывно связанной с BDD, является Specification by Example (Спецификация на основе примеров, SbE). Она имеет и другие названиями, подчеркивающие влияние результатов, полученных с ее помощью, на все стадии процесса разработки: example-driven development, Agile Acceptance Testing, Test-Driven Requirements. Собственно ничего принципиально нового в приведении примеров в качестве иллюстраций логики работы системы нет. Однако, благодаря публикациям Гойко Аджича (Gojko Adzic), формализовавшего подход, методика стала мощным средством общения в проекте. Суть ее сводится к использованию примеров в ходе обсуждения требований как с бизнесом, так и с командой с последующим внесением их в документацию. Разработанные в ходе сбора требований примеры служат единым источником информации и применяются в последующих фазах: становятся техническим заданием для реализации, ложатся в основу тестовых сценариев, демонстрируют разработанную функциональность пользователям на этапе внедрения. Формат описания примеров рекомендует выделять входящие параметры и результаты работы приложения, а также сопровождать примеры описанием контекста - выполняемых шагов процесса. Таким образом, примеры фактически представляют собой исполняемую спецификацию, т.е. набор сценариев, пригодных для ручного тестирования и легко поддающихся автоматизации.

Изначально рекомендаций относительно используемых нотаций техники Specification by Example и Acceptance Criteriaне не содержали. Acceptance Criteria описывались в свободном формате. Specification by Example, как правило, представляли собой таблицы с комментариями. Однако, по прошествии 10 лет развития подхода можно сказать, что с большим отрывом лидирует Given-When-Then, или так называемая,Gherkin нотация.

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

Безусловно на распространение этой нотации повлияло и ее использование фреймворками автоматизированного тестирования. Разработанная первоначально в рамках Jbehave , она сейчас поддерживается всеми популярными приложениями этого класса, включая такие как Cucumber и SpecFlow. Язык Gherkin расширяет шаблон Given-When-Then дополнительными ключевыми словами и делает его полноценным средством описания сценариев, сохраняя при этом краткость. Многие приложения, например Cucumber, позволяют включать в описание таблицы, что дает возможность сделать сценарии более лаконичными, структурированными и улучшает читаемость.

Комбинация описанных техник, удобная нотация в сочетании со средствами автоматизации процесса разработки, интегрированными в единый CI/CD цикл, служат мощным инструментарием для реализации BDD.

Казалось бы, следуя этой методологии и вооружившись лучшими практиками, наработанными за последнее десятилетие, сформулировать критерии приемки так, чтобы они сразу были переданы на автоматизацию, не должно составить особого труда. Именно так я видела свою задачу сбора требования. Однако, после проработки нескольких пользовательских историй, мне пришлось признать, что мои попытки потерпели фиаско. Написанное мной было далеко от того, что можно было автоматизировать. Чего-то в предложенных сценариях не хватало.

Я находилась в некотором замешательстве, пока не вспомнила о BDD треугольнике, в котором John Smart выделил понятия требований, примеров для иллюстрации требований и исполняемых спецификаций для тестирования разработанного программного обеспечения согласно требованиям. Действительно, при всей похожести этих сущностей и перетекании их друг в друга, каждая из них остается самостоятельным артефактом со своими особенностями.

Также в литературе помимо критериев приемки (Acceptance Criteria, AC) используется понятие приемочных тестов (Acceptance Tests, AT). Чем они отличаются? Критерии приемки, как всякие требования, выражают потребности, отвечая на вопрос, что должно быть сделано. Приемочные тесты проверяют как именно эти потребности будут удовлетворены. Эти артефакты относятся к разным фазам процесса разработки: фазе сбора требований и фазе тестирования, между которыми происходит непосредственно реализация. Иными словами, последние завершают разработку, начатую первыми. Комбинация обоих должна гарантировать максимальную ценность решения для заказчика. Согласно BDD и те и другие должны быть сформулированы до начала реализации.

Исходя из этих соображений, можно предположить, что подход к описанию критериев приемки и приемочных тестов должен быть различный. Хорошие требования должны определять поведение системы в любых условия. Для этого в описании могут быть использованы качественные характеристики, интервалы данных. Тестовые сценарии должны обеспечивать покрытые, достаточное для того, чтобы судить о надежности использования решения. Они должны содержать точные количественные значения параметров.

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

Для демонcтрации сказанного рассмотрим пример требований к выполнению операции денежного платежа (конечно, в упрощенном виде).

Требования сформулированы в виде критериев приемки, представляющих собой описание процессов с использованием Given-When-Then нотации: основного процесса операции и альтернативных процессов в случае обнаружения ошибок при проверке введенных параметров. Описание дополнено бизнес-правилом расчета комиссионных, проиллюстрированным примерами, а также правилами валидации введенных значений. Описание рассчитано на обсуждение с пользователем. Для облегчения восприятия оно фокусируется на основных шагах взаимодействия и опускает очевидные утверждения относительно стандартного поведения системы.

AC1. Main flow Given пользователь подтвердил полномочия и получил доступ к платежным операциям When пользователь вводит верные параметры платежа, Then система пересчитывает сумму операции с учетом комиссионных When пользователь подтверждает параметры платежа Then операция выполняется AC2. Alternative flow Given пользователь подтвердил полномочия и получил доступ к платежным операциям When пользователь вводит неверные параметры платежа Then операция запрещена BR1 (Business Rule): Комиссионные составляют 10% суммы операции, но не менее 10 у.е. SbE (Specification by Example) Если пользователь вводит <Сумма платежа>, то система рассчитывает <Сумма комиссионных> и <Общая сумма операции>

BR2: Сумма операции не может превышать баланс счета. BR3: Счет получателя должен быть зарегистрирован заранее.

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

AT1. Main flow

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

And баланс счета составляет <Баланс>

When пользователь выбирает <Счет получателя>

And пользователь вводит параметры платежа: <Дата операции>, <Сумма платежа>

Then пересчитанная сумма операции с учетом комиссионных составляет <Общая сумма операции>

And проверка внесенных данных проходит успешно

And подтверждение операции запрашивается у пользователя

When пользователь подтверждает параметры платежа

Then транзакция попадает в журнал выполненных операций

AT2. Alternative flow. Cancellation Given пользователь подтвердил полномочия и получил доступ к платежным операциям And баланс счета составляет Баланс =150 When пользователь выбирает Счет получателя = 124233 And пользователь вводит параметры платежа: Дата операции= 02.02.21, Сумма перевода = 100 Then пересчитанная сумма операции с учетом комиссионных составляет Общая сумма операции = 110 And проверка внесенных данных проходит успешно And подтверждение операции запрашивается у пользователя When пользователь отменяет операцию Then транзакция не попадает в журнал выполненных операций AT3. Alternative flow. Exceptions handling Given пользователь подтвердил полномочия и получил доступ к платежным операциям And баланс счета составляет <Баланс> When пользователь выбирает <Счет получателя> And пользователь вводит параметры платежа: <Дата операции>, <Сумма перевода> Then проверка внесенных данных не проходит успешно And<сообщение об ошибке> выводится на экран And транзакция не попадает в журнал выполненных операций

Таблица ниже дает более развернутое сравнение характеристик критериев приемки и приемочных тестов

Так чего же не хватало моим сценариям? Чего вообще недостает критериям приемки, чтобы стать приемочными тестами? Как обычно дьявол кроется в деталях. И в нашем случае это детали реализации. Детали реализации, безусловно, базируются в первую очередь на требованиях. Однако, они также обусловлены условиями разработки, применяемыми стандартами, ограничениями используемых технологий и даже субъективными предпочтениями стейкхолдеров.

Откуда берутся эти детали? Из того самого сотрудничества и общения, о которых говорится в определении BDD. Организация этого общения и есть первоочередная задача проектной команды. Одной из самых популярных практик является сессия 3 Amigos, на которой должны быть представлены три мнения: бизнеса, разработчиков и тестировщиков. Есть много рекомендаций на счет ее длительности, времени проведения и количества участников. Команда вольна следовать им или нет, выбирая наиболее удобную для себя форму. Главное помнить слова одного из создателей и активного пропагандиста BDD Джона Смарта (John Smart) о том, что независимо от названия и формы общение есть неотъемлемой частью BDD. Без общения нет BDD.

Тренинги от "Art of Business Analysis"