«Вначале язык может показаться неудобным». Опыт использования BDD/Gherkin на проектах

Какой у тебя профессиональный опыт в ИT? 

Я шёл в эту сферу со школьных лет, можно сказать. Учился в Лицее БГУ на математическом отделении. Потом поступил на ФМПИ, занимался на кафедре «Технология программирования». Работать начал на последних курсах университета, писал на C++. После университета пришёл в ISsoft, после распределения ненадолго ушел в другую компанию, ну а затем вернулся обратно. В общем — около 15 лет опыт промышленной разработки. Основной стек — .NET, но я стараюсь быть в теме и расширять свой кругозор за счёт различных технологий.

А как получилось, что ты, .NET архитектор, стал руководить отделом QA Automation? Как давно ты погружён в тестирование?

Ну, в теме, так сказать, я достаточно давно.  Всегда считал, что должен знать, что происходит на проекте: кто что делает, за что отвечает. А как без этого? Кроме того, мне нравится работать в команде, координировать усилия различных специалистов, видеть прогресс моих коллег. Ещё в начале карьеры я интересовался работой тестировщиков и никаких предубеждений у меня нет.  В общем, я погружён в тестирование уже лет 12, а глубоко — полтора года, с тех пор как стал руководителем отдела QA Automation.

Тема твоего доклада: Внедрение BDD/Gherkin. Что такое Gherkin?

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

Behavior-driven development как практика чаще всего преподносится как развитие Test-driven development. При TDD подходе разработчики стараются писать код так, чтобы без проблем выполнялись его проверки. Сначала создаются проверки, которые не выполняются, потому что нет продукта, который этим проверкам удовлетворяет. А потом уже пишется код продукта, который действительно соответствует этим проверкам. BDD подход описывает поведение пользователя. Создавая описание этого поведения на Gherkin, мы получаем легкий шаблон спецификации. Смотрите сами: достаточно указать условие «given», «when» — конкретное действие пользователя, «then» — результат этого действия. Больше про Gherkin сейчас рассказывать не буду. Главное — возможность интеграции этих слов на обычном языке с кодом, который проверяет, что происходит. Всё остальное расскажу на конференции ISsoft Insights.  

Твой доклад основан на практическом опыте. С какими проблемами пришлось столкнуться?

Нужно понимать, что BDD должен использоваться всей командой проекта. Менеджеры, аналитики, команды разработки и тестирования должны быть готовы строить свою работу по BDD. Воспринимать BDD/Gherkin просто как инструмент автоматизаторов в корне неправильно. Можно, конечно, писать кейсы сначала на Gherkin, а потом их автоматизировать. Но это не Behavior-driven development.

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

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

В чём преимущества BDD-подхода?

На конференции я расскажу много полезного из своего опыта. Пока могу сказать, что в первую очередь данный подход обеспечивает полную интеграцию между всеми этапами разработки. Не зря его считают одной из важных практик в Aglie. BDD позволит не только не терять информацию на отрезке BA-QA, но и экономить время. Например, сегодня мы что-то сделали, а вот прошло полгода и эта информация не потеряна. При этом мы вроде бы и по-простому ее задокументировали, хотя обычно «взять и задокументировать» на деле не так просто, а тем более — поддерживать документацию.

Ещё я поделюсь краткой информацией о том, какими техническими средствами оно реализуется. Вкратце — потому что не хочу перегружать выступление технической информацией. Я буду приводить практические примеры из работы двух команд, которые трудятся с BDD. Расскажу о проблемах и их решении, предложу несколько BDD-сценариев.

Что касается технических средств. Насколько универсально применение BDD/Gherkin?

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

Существуют инструменты, например, Cucumber, которые позволяют подружить Gherkin с различными языками программирования: Java, Ruby и пр.

Ты упоминал, что будешь рассказывать про эту тему подробнее. Где и когда можно будет послушать твоё выступление?

На конференции ISsoft Insights, которая пройдет 2 июня в Минске. Она бесплатная, можете приходить. Там я поделюсь своим опытом внедрения BDD/Gherkin на проектах, расскажу, что стало лучше, а что наоборот. Будет много полезного и того, что точно заставит вас воскликнуть: почему я ещё не использую BDD?!

Эта публикация подготовлена в партнёрстве с ISsoft

Что такое партнёрский материал?

Иностранное производственное унитарное предприятие «ИССОФТ СОЛЮШЕНЗ»
УНП 190819327