Используете ли вы BDD по назначению?

общие вопросы
, , , ,
#21

Я как раз эту тему поднимал в своём докладе на последнем SeleniumCamp:

“Bullshit driven development”
http://seleniumcamp.com/materials/bullshit-driven-development/

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

Изначальная цель BDD - это вовсе не отчёты, а написание спеков ВМЕСТЕ С БИЗНЕСОМ, и этого нигде не происходит. Как тут правильно заметили, того же результата гораздо проще добиться обычным кодом на обычном языке программирования.

9 лайков
#22

Да, мне понравилось, как в роботе исторически появился BDD. На вопрос “а где у вас модный BDD”, разработчики простым коммитом добавили поддержку ключевых слов, но не стали “впаривать” это, как святой грааль. В итоге в тестах нет жестких ограничений, тестировщик сам выстраивает нужную ему лаконичность и стиль, не привязывается к “красивым” отчетам (они и так приемлемые).

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

1 лайк
#23
  1. Андрей основную причину хорошо описал. И у нас бизнес не пишет сценарии.
  2. Тратим время на создание лишнего кода (мапинг степов jBehave & Java). Зачастую в шаге просто инициализация объекта страницы + вызов одного метода, например клик по элементу.
  3. Передача контента между шагами.

Очень хороший пример от Паши:

к чему-то такому буду и я стремиться, только буду PageObject подход использовать. Думаю будет выглядеть как-то так:

@Test
public void userCanSearch() {
   GooglePage page = open("http://google.com", GooglePage.class);
   page.searchFor("Selenide: concise UI tests in Java")
   .getResults().get(0)
   .shouldHave(text("Selenide: concise UI tests in Java"));
}

Такой тест написать быстрее чем создавать дополнительные классы с мапингом. Может даже девелоперы будут писать UI тесты :relaxed:
Я простенький POC написал, как бы я реализовал это, Кстати, буду рад за конструктивные замечания.

#24

А как это у Вас получается? Можете примерно описать, что за продукт и как достигается “стандартный код”, дать примеры такого кода?

Эммм… Вы знакомы со структурой Gherkin? Ну, то есть как в feature файле описывается тест?
Если да, то я удивляюсь откуда возникает этот вопрос.

#25

Давайте соберем немного статистики:

Считаете ли Вы BDD оправданным подходом?

  • да, BDD - полезный подход
  • нет, BDD - это утопия
  • не знаю, не определился

0 участников

Зачем Вы используете BDD?

  • это неотделимая часть процесса
  • для взаимодействия команды с заказчиком
  • чтобы стандартизировать разработку
  • чтобы улучшить процесс тестирования
  • чтобы автотесты писали не программисты
  • для построения красивых отчетов
  • для упрощения создания автотестов
  • для написания документации
  • это требование заказчика \ клиента
  • это требование менеджмента

0 участников

Хотели бы Вы использовать BDD подход в будущих проектах?

  • да, буду использовать
  • посмотрим, все зависит от контекста
  • нет, не буду использовать
  • не знаю, точно не могу сказать

0 участников

#26

Использую в течение двух лет. После написания (и поддержки!) тестов в отрыве от спецификаций - глоток свежего воздуха.

Завершенный недавно проект делали два года. Результат - порядка 5000 автотестов на UI, покрытие 93% от автоматизируемых (от общего - кажется порядка 70, уже не помню), при этом тесты в CI в целом зеленые (падений порядка 1%).

Sapienti sat.

#27

Расскажи пожалуйста подробнее как процесс был построен:

  1. кто писал спецификации на геркине?
  2. что дальше происходило - как дальше шаги автоматизировались?
  3. получалось успевать автоматизировать спецификации в спринте или уже после дописывались, в качестве регрессионного тестирования?
  4. процентное соотношение участников по ролям в команде: кто писал код (сам продукт), кто спецификации, кто автоматизировал, кто тестил вручную и т.д.?

Первая success story в треде - очень интересно узнать подробности :smile:

#28
  1. ручной QA он же FA. Для ускорения и упрощения были согласованы типовые шаги как для работы с UI так и с моканым сервером, собственно ими пользуются уже 4-5 команд.
  2. тесты были готовы к началу разработки или хотя бы близко к концу) Дальше они приходили ко мне (автоматизатору). В других командах выделенного автоматизатора нет, автоматизируют девелоперы, процесс не меняется.
  3. Автоматизация - в DOD истории, но естественно иногда историю заканчивали к концу спринта и автоматизация уходила на следующий. 50х50, в начале разработки чаще, т.к. когда вообще ничего нет, автоматизировать невозможно.
  4. Типовая команда когда я приходил - 4 Dev, 1 QA, 1 TA. В команде доходило временами до 8 Dev. Процесс примерно такой - требования формализованы заранее, тесты (в виде заголовков как минимум) готовы к началу разработки. Это конечно утопия, при старте все начинает ползти в разные стороны) Если фича дополняет существующую, получалось натуральное БДД - часть шагов уже была автоматизирована в предыдущих фичах, я доделывал разметку и дописывал пару-тройку новых шагов. После чего прогонял тесты, находил баги и отдавал девелоперам вместе с тестами. Тесты в таком случае делаются в том же фича бранче и там же озеленяются. Если фича новая то пока ее не соберут никакого бдд не выйдет) поэтому автотесты писались уже после мержа в девелоп в таком случае.

Ручное тестирование - после мержа в девелоп ветку, оно всегда делалось в конце спринта на релиз кандидате. CI гоняет тесты текущего спринта или релиза (зависи от обьема) и смок пак по коммитам (изза загрузки агентов примерно раз в час), регрессия - ночной прогон всех паков.

Регрессию тоже кстати автоматизировали вендорами - спецификации писали изначально на геркине. Правда пришлось инвестировать тучу часов в переделку спецификаций которые нафиг устарели за три года и были абсолютно не адекватны реальности.

p.s.
Я буду докладать на SQA Days в Минске через неделю) если кто будет - подходите, пообщаемся. :slight_smile:

3 лайка
#29

Спасибо за ответ. Из описанного я лично вижу, что твой случай - исключение, подтверждающее правило.

Попробую логически объяснить причины успешного использования BDD в данном случае (исходя из того, как я понял). Если что навру, пожалуйста, поправляйте:

  1. Если QA (кто такой FA?) может писать спеки до начала разработки фичи, то он либо сочетает в себе роль бизнес-аналитика, либо это настолько простая предметная область, либо этот QA очень (очень-очень) тесно взаимодействует с аналитиками, владельцем продукта и заказчиком
  2. В остальном описанное тоже лишь подтверждает вышеприведенные комментарии

То есть BDD - это про организацию процесса, а не про язык описания сценариев (человеческий vs. программный).

Еще вот такой вопрос интересен: есть ли профит именно от того, что использовался gherkin (и соответствующий BDD-фреймворк для автоматизации)? По-моему чисто от gherkin и BDD-фреймворка (cucumber, specflow, etc) может быть польза в том случае, если промежуточное звено между спекой и её автоматическим выполнением (собственно, сами автоматизаторы) отсутствует. Тогда будет тот самый эффект. А когда степы всё равно приходится автоматизировать, то какая разница на каком языке написаны сценарии: GWT или простой человеческий? Если они написаны и написаны правильно (декомпозированы в тесткейсы, которые легко автоматизировать 1-в-1)

#30

Сначала отвечу на вопрос: FA - Functional Analyst - промежуточное звено между QA и BA, понимает бизнес и может обьяснить разработчикам/QA что это значит. В чистом виде в природе почти не встречается :о)))

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

BDD само по себе - применимо там, где применимо. Без поставленного процесса равно ни BDD, ни даже прости господи Waterfall в миссионерской позиции. :о))

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

Профит геркина для автоматизации - да, есть. Об этом я буду говорить послезавтра в Минске как раз. Кратко и тезисно: грамотно используя specflow мы радикально уменьшаем обьем codebase для автоматизации. Это - кост на саппорт. Если делать неграмотно - никакого профита не будет. Но ведь это относится к любой технологии. Следующий вопрос - как делать грамотно… :о)))

Отвечая на вопрос впрямую. Прослойка между автором сценария и приложением (автоматизатор). Тут основная роль - грамотно построить грамматику языка таким образом, чтобы минимизировать количество шагов и сделать их как можно более универсальными. Разница очень простая. Грамотно параметризованный степ в GWT - не нуждается в новом коде. Если подходить математически - каждый новый сценарий, использующий данный степ без геркина - порождает 1 новую строку кода. С геркиным - только 1 новую строку при “инициализации”, последующее использование - бесплатно.

Отсюда вывод лично мой. Если писать маленькие фичи мало связанные с другими - профит будет невелик. Это относится к примеру Math Idiot который идет вместе со SpecFlow, например. Если живешь в большом проекте, где UI постепенно развивается в рамках одного бизнес flow, чем дольше разработка, тем дешевле автотесты. (в традиционном подходе это далеко не так).

Уфф) накатал же я простыню.

#31

А теперь я наконец прочитал исходные проблемы)

  1. Это справедливо в случае любого инструмента, разве нет?

  2. Передача данных между степами решается элементарно как штатными средствами SpecFlow, так и написанием собственного сервиса. Кроме того, зависимые шаги (я считаю, заслуженно), считаются анти-паттерном. Если правильно указать входные данные (и конечно правильно расставив моки), без этого можно обойтись.

#32

Я попробую объяснить, в чём дело с “привычной картиной мира”. Если память мне не изменяет, проблему соответствия языка реальности обдумывал ещё Аристотель. То, что за столько столетий человечество на самом деле не продвинулось в универсальных языках, должно было бы наводить энтузиастов BDD на некоторые мысли.

Вы вот пишете:

[quote=“egovako, post:30, topic:7081”]
Тут основная роль - грамотно построить грамматику языка таким образом, чтобы минимизировать количество шагов и сделать их как можно более универсальными. Разница очень простая. Грамотно параметризованный степ в GWT - не нуждается в новом коде.
Если подходить математически - каждый новый сценарий, использующий данный степ без геркина - порождает 1 новую строку кода. С геркиным - только 1 новую строку при “инициализации”, последующее использование - бесплатно. [/quote]

Это, если я не ошибаюсь, говорится что BDD подходит если на проекте можно разработать некий “универсальный язык”, хорошо описывающий проект. Если. В Вашем случае продукт оказался таковым что такой язык получился, нашлось кому его грамотно разработать и старый добрый и всеми любимый code reuse получался хорошим даже несмотря :wink: на Геркин.

Но вот я выше описываю совсем другой случай. Где универсального языка, описывающего SUT, скорее не может быть, ввиду большой вариабельности компонентов, составляющих эту самую SUT и их неоднозначного поведения (ибо оно крайне кастомизировано и в разных настройках и инсталляциях продукта user flows) могут быть очень разными.

В этом случае Gherkin reuse становися крайне проблематичным, и получается что вместо reuse на тех, кто хочет описывать всё стандартными степами падает задача непосильной сложности — они пытаются уложить в стандартный язык очень сложную систему реального мира.

Отсюда можно вывести и правило применимости (и нужности) BDD: если SUT хорошо сводима к некоему универсальному формальному языку и возможности step reuse просматриваются совершенно неиллюзорно, тогда в этом есть профит :smile:

Но вот если система очень разносторонняя и кастомизируемая, и разрабатывать хороший и правильный и универсальный язык, описывающий поведение системы, особо некому —
тогда браться за Gherkin это сизифов труд.

А теперь давайте прикинем, каких систем в мире больше —
хорошо формализуемых в не очень объёмный язык с большими возможностями повторного использования или может каких-то других.

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

Вот потому я и присоединяюсь к тезису, что хороший профит от BDD скорее исключение, а не правило.

“Простыню” он написал, хе :smile:

1 лайк
#33

Ну и ещё парочка следствий по вышеизложенному:

  • краткосрочному проекту “с индивидуальностью” BDD нужен как рыбке
    зонтик
  • если вам некогда думать о языке BDD, а надо педалить код, то может
    не надо мучить маппингом BDD на приожение себя и других?
#34

Я бы, таки, упомянул не Аристотеля, а Кнута и литературное программирование. Вот когда из stories будет формироваться сам код приложения - тогда можно будет говорить, что BDD самодостаточная система.
Но на данном этапе, это обычный keyword-driven, со словами-маркерами “если”/“то”, которые необходимы исключительно для упорядочивания мыслей “писателя историй”.

#35

смотрю сейчас ваше выступление
грамотные мысли )

1 лайк
#36

Круто! Спасибо.

#37

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

2 лайка
#38

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

1 лайк