BDD в 1С

Проблемы коммуникации между бизнесом и IT

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

Итак, давайте поговорим про взаимоотношения бизнеса и IT.

Первая проблема, которая очевидная всем это то, что мы с бизнесом говорим на разных языках.

Это известная проблема, что бизнес мыслит и говорит в одних терминах, а IT мыслит и говорит в других. Мы технари - они бизнесмены. Все вы прекрасно знаете, как бывает трудно понять заказчика. Иногда даже приходит мысль, что для понимания друг друга, нам нужен другой, общий язык. Что-то типа эсперанто, только для бизнеса и IT.

Методика BDD разрешает эту проблему.

Вторая проблема, это то, что бизнес никогда не знает, полностью ли соответствует ли написанное ПО его требованиям, или нет.

Да, пусть мы с бизнесом согласовали требования к будущей системе. Но вы прекрасно знаете, что в современном динамичном мире, требования постоянно уточняются, дополняются. У бизнеса появляются новые идеи, а IT приходится вновь и вновь перекраивать систему. Если ПО разрабатывается большое и сложное, то в полный рост встаёт проблема, а как понять, эта программа сейчас делает именно то, что нужно бизнесу? Как IT продемонстрировать результат своей работы, чтобы заказчик был уверен, что он получит то, что хочет.

Эту задачу мы тоже можем решить с помощью BDD.

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

Эта проблема тесно связана с предыдущей. Когда бизнес постоянно растёт и изменяется - вмести с ним изменяются и требования к ПО. Это все понимают. Со стороны IT это проявляется, как постоянная доработка, переделывание, рефакторинг уже существующих подсистем.
Как защитить уже работающий функционал? Как проверить, что при суровом рефакторинге, мы ничего не сломали? Даже какая-нибудь простая задача, например, разделить функционал одного документа на два, может вылиться в чистый хаос, ведь надо убедится, что все связанные части системы, такие как регистры, отчетность - не поплыли из-за этих изменений.

Эту проблему мы тоже можем решить с помощью BDD.

Что предлагает BDD для того, чтобы решить эти проблемы теоретически?

Давайте обозначим, как все это будет происходить:

• Проблема коммуникации с заказчиком (то, что мы с ним говорим на разных языках) в BDD решается с помощью специального «объединяющего языка», который называется Gherkin. На нем описываются требования, которые понятны и бизнесу, и IT.
• Проблема того, что бизнес не знает, до конца ли соответствует ПО его требованиям, может быть решена, если мы дадим заказчику в руки инструмент, позволяющий по нажатию одной кнопки посмотреть, как в его системе в данный момент работает интересующая его функциональность.
• А что касается того, что каждый новый цикл разработки становится все дольше и дольше – для этого существуют практики Continues Integration и  Continues Delivery.

Процесс разработки по методике BDD

Методика BDD позволяет нам по-новому рассмотреть процесс разработки. Кубики, из которых строится эта методика, остаются все теми же. Но BDD позволяет взглянуть на них по-новому:

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

Описание требований в BDD

Теперь перейдем к практике.

Если вы будете гуглить BDD в интернете, то найдете примеры типа: «как сложить 2+2», или «как умножить два числа» и т.д. А я вам приведу конкретный пример для типовой бухгалтерии – «Зачет аванса».

Итак, мы уже говорили, что в BDD требования пишутся на определенном языке, который называется Gherkin. Этот язык еще называют Given When Then – это английская терминология.

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

Давайте рассмотрим конкретный пример – «Зачет аванса».

• Итак, на самом верху, в начале текста у нас содержится ключевое слово «Функционал». Здесь мы в свободной форме описываем, что нам нужно. Например:
  • Функционал: Распределение поступающей оплаты по документам реализации и зачет аванса контрагента.
• В середине идет более важная часть, где описывается бизнес-полезность этого функционала (кто его заказывает и для чего это нужно). Например:
  • Как бухгалтер (это действие будет делать бухгалтер), я хочу, чтобы при фиксации оплаты от контрагента происходил зачет аванса для того, чтобы получить корректные проводки.
• И ниже описывается реальный сценарий, как это будет происходить:
  • Допустим, есть контрагент, имеющий долг 900 рублей, когда по нему фиксируется оплата на 2000 рублей, тогда на 62 счете формируется две проводки.

Так выглядит реальный кейс, реальный пример для типовой конфигурации.

Соответственно, я хотел бы обратить внимание, что данный текст, как сценарий работы, понятен как IT-специалистам, так и бизнес-пользователям – здесь ничего особенного для них нет.

Генерация сценариев поведения из текстов требований

Идем дальше. Мы говорили, что у нас по одной кнопке будут генерироваться сценарии тестирования. Для этого мы будем использовать инструмент Vanessa-behavior. О нем чуть подробнее:

• Это инструмент из семейства Vanessa Stack.
• Это опенсорс-продукт, в разработке и доработке которого может принять участие любой из вас.
• Он free for commercial use (бесплатный для использования).
• По сути, это – генератор сценариев тестирования и «запускалка» (так называемый feature-плейер): мы загружаем в него свои требования, нажимаем на кнопку, и они начинают у нас магически воспроизводиться.

Давайте посмотрим на код, который получился в результате обработки нашего требования (того самого кейса с зачетом аванса).

Каждый описанный шаг нашей «фичи» превратился в процедуру, которая по умолчанию содержит в себе код:

ВызватьИсключение"Не реализовано"

Так сделано специально, потому каждый шаг в BDD – это аналог теста из TDD. И у каждого шага может быть три состояния:«Выполнено», «Не выполнено» и «В ожидании реализации».Таким образом, мы в BDD всегда знаем, какой процент требований у нас сейчас реализован, поскольку мы всегда получаем отчет о том, приступал ли вообще программист к реализации конкретного требования или нет.

Обратите внимание на то, что генерируется именно epf-файл – не просто код, а готовая epf-обработка, которую мы сразу можем загрузить в конфигуратор, чтобы там с ней дальше работать.

Автоматическое воспроизведение шагов сценария поведения

Мы говорили о том, что дадим заказчику «волшебную кнопку», с помощью которой он сможет проверить реализованную функциональность. В нашем инструменте Vanessa Behavior есть такая кнопка – она называется «Выполнить сценарии».

С ее помощью IT-специалисты могут производить демонстрацию функциональности заказчику: они загружают фичу в feature-плеер, нажимают кнопку, и начинают появляться окошки, где автоматически вводятся данные, проводятся документы и пр. Вообще говоря, бизнес-заказчик может провести это демо и сам для себя, он может загрузить фичу, нажать кнопку и также убедиться, что все работает. Например, вы можете ему прислать свои изменения и попросить: «Проверьте, пожалуйста», - «Хорошо, проверяю». Это может работать и так.

Использование готовых шагов сценария из каталога библиотек

В BDD является нормой такой термин, как «повторное использование кода». Что это такое?

Представьте себе: мы описываем шаги сценария для нашей «фичи», генерируем по ним epf-обработку, загружаем ее в feature-плеер и видим, что часть из этих шагов сразу закрасилась в серый цвет – это означает, что такой шаг уже реализован в одной из библиотек. Обратите внимание, мы с вами просто написали сценарий, даже еще ничего не программировали,просто в блокноте написали, а этот сценарий уже сразу может работать – будут исполняться его шаги, проводиться документы и т.д.

В BDD это является нормой. Это связано с тем, что происходит переиспользование готовых шагов, которые кто-то до нас уже реализовал.

Отличия BDD и TDD

Методика BDD выросла как развитие подхода TDD (разработка через тестирование). Как это получилось? Люди при внедрении разработки через тестирование в различных системах столкнулись с определенными проблемами. Соответственно, как ответ на эти проблемы – Ден Норт сформулировал подход BDD.

Я хотел бы подчеркнуть ключевые отличия – почему для 1С BDD подходит лучше, чем TDD. Смотрите:

• И там, и там сценарии тестирования пишутся до кода. В TDD это происходит нативно, он так устроен, а BDD – это продолжение TDD, работает точно так же.
• Прямая связь с требованиями. Здесь я имею в виду, что мы по одной кнопке получаем сценарий тестирования. В TDD такого нет. В BDD это есть.
• Повторное использование кода – нативно в TDD этого нет. Там вы должны постоянно думать о том, как избежать дублирования в тестах, придумывать для этого какие-то общие модулии т.д. В BDD это работает само собой.
• Сценарии поведения UI. Тот, кто внедрял TDD, понимает, что писать UI-тесты для 1С на чистом TDD очень сложно. Это низкоуровневая методика, она немного не для этого. Низкоуровневые тесты для 1С – очень редкая задача: мы не пишем dll в 1С, мы автоматизируем бизнес, описываем поведение системы. Заказчик хочет получить не процедуру в модуле, а чтобы система вела себя определенным образом. Соответственно, BDD – это разработка через поведение системы. Поэтому оно на 1С так хорошо и ложится.

Автоматизированный отчет о тестировании в формате Yandex Allure

Мы говорили, что можно по нажатию одной кнопки получить отчет о качестве. Для этого нам понадобится билд-сервер (он же CI-сервер, Continues Integration сервер). Им может быть, например, Jenkins. Почему Jenkins? Потому что он бесплатный, вы можете его кластеризовать и масштабировать как захотите. Например, можете настроить его так, чтобы после каждого изменения в хранилище он выгружал вашу конфигурацию в отдельную базу и прогонял на ней тесты. Скажем, ваш программист поместил изменения в хранилище, Jenkins их себе затянул, поднял базу, запустил все сценарии на выполнение и выдал вам отчет на email.

Здесь на скриншоте как раз можно увидеть отчет для Jenkins в формате Yandex Allure. Спасибо ребятам из Яндекса, которые его разрабатывают. Его функционал также доступен в виде плагина для Jenkins. Соответственно, для того, чтобы получить такой отчет из Jenkins, вам надо всего лишь сделать пару кликов мышкой.

Окупается ли разработка через тестирование

Очень часто задают вопрос: окупается ли разработка через тестирование? Как могут вернуться затраты, которые мы понесем на обучение команды, на софт, железо?

Давайте посчитаем, что нужно для того, чтобы запустить BDD:

• Jenkins – бесплатный.
• Vanessa Behavior – бесплатный.
• Отчет Yandex Allure – бесплатный.
• Безусловно, нам нужно «железо», но дело в том, что для работы билд-сервера хватает компьютера уровня обычной рабочей станции пользователя. Можно даже несколько таких станций поставить, кластеризовать, и у вас получится кластер Jenkins – с мастер-нодами, со slave-нодами – все по-взрослому.
• Остается только обучить людей. Но это – «камень преткновения», потому что вначале программистам будет трудно, им надо перестраивать свой процесс разработки.

Так почему же все это должно окупиться? Откуда возьмется профит? Почему у нас вернутся инвестиции?

Здесь ключевая «фишка» в «техническом долге». Известно, что до 20 процентов своего времени каждую неделю программист должен отдавать на возвращение «технических долгов». Что такое «технический долг»? Это когда мы некачественно выполняем свою работу: где-то «костыль», где-то мы написали «НайтиПоКоду», где-то в архитектуре что-то сделали не так, как надо, потому что нас бизнес «теребил», и нужно было закончить быстрее. Это называется «технический долг» – мы сами себя немного «подставляем» в будущем, создавая проблемы, которые нам же потом придется разгребать (или тем, кто будет сопровождать систему).

Так вот, запуск инженерных практик позволяет поднять качество разработки. А за счет повышения качества разработки мы отдаем свои «технические долги» и НЕ накапливаем новые.

Согласно расчетам, которые мы проводили на наших проектах:

• Срок обучения IT-специалистов таким практикам – где-то 3 месяца, после этого затраты на обучение уже сводятся к нулю.
• А срок окупаемости – до года, может быть, даже быстрее (9 месяцев и т.д.)

Но за счет того, что мы не создаем себе проблем в будущем, качественно работаем «здесь и сейчас», то время, которое мы бы тратили на отдачу своих «технических долгов», мы можем перенаправить на что-то полезное для бизнеса, чтобы быстрее выпустить какую-то функциональность и тем самым принести дополнительную прибыль. Так это работает.

Планы по развитию

Планы по развитию нашего инструмента – Vanessa Behavior:

• Мы будем накапливать библиотеки, чтобы еще больше увеличить процент повторно используемого кода. В идеале хотелось бы, чтобы шаги сценариев тестирования появлялись сразу на этапе написания требований, чтобы программисту не приходилось их описывать с нуля. Нам для этого нужны библиотеки, и мы это будем развивать.
• Написание feature-файлов для типовых конфигураций. Мы работаем с Бухгалтерией, с перепиленным УПП, ЗУП, некоторыми другими конфигурациями. Поэтому мы собираемся накапливать feature-файлы, покрывающие их типовой функционал, а также тот функционал, который мы сами дорабатываем.
• Развитие BDD Editor. В процессе внедрения практик BDD выяснилось, что хочется писать feature-файлы еще удобнее, еще быстрее – не просто в Word их писать, а сразу мышкой набрасывать. Для этого мы разрабатываем специальный инструмент – BDD Editor. Он позволит сделать это еще лучше,еще эффективнее.

Ссылки по проекту

Ссылки по проекту:

• Мой ник на github – https://github.com/Pr-Mex
• Ссылка на проект Vanessa Behavior – https://github.com/silverbulleters/vanessa-behavior

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.