testomat.io управление авто тестамиПрошло 3 года с момента создания темы :
Интересно поменялось ли ваше мнение спустя время и обновления? БДД все так же хлам или крутая штука? Когда бы вы использовали BDD а когда нет?
По-прежнему ненужный слой абстракции, от которого нет профита. Менеджеры рады, а автоматизаторам поддерживать этот бред.
6 лайков
Да что-то и менеджеры особо не рады. Они будут рады если у вас отчеты будут в таком же стиле описаны, а для этого необязательно всю эту кашу с BDD заваривать)
Я участвовал в двух проектах с BDD. Один поднимали с нуля, второй - подняли немного ранее до меня.
В общем, обещали огромное количество людей, которое будет писать автотесты на русском языке, вы только действия сделайте…
Действия сделаны, и это оказалось никому не нужно 
Так что в печь этот BDD.
5 лайков
BDD как и любой keyword-driven подход может страдать от такой ситуации. Но в основе её людская лень и раздолбайство руководителей и исполнителей, а не конкретно BDD-шная болячка.
Человек в целом ленивое существо. И старается делать что-либо с минимум усилий. Это естественно.
Допустим есть два ресторана, в одном моют кухню и туалеты хорошо, а в другом - нет. Потом кто-то приходит, видит второй ресторан и говорит, что уборка не работает и это лишний труд. Я это так вижу сейчас.
Точно такой же “холивар” можно устроить на тему тест-кейсов. Я видел лишь раз проект, где они заводились и сопровождались хорошо и огромное число тех, где они были лишь для “галочки”. Если судить только по худшим представителям, то можно любую технологию и методологию сдавать в утиль.
6 лайков
Наверно в энтерпрайзе БДД реально может быть полезен только если его можно
синкать с жирой-зефиром.
Если есть пример или POC буду признателен за линку.
Абстрактные мысли:
по сути это наверно должна быть либа которая по апи будет синкать тесты, степы и экзекушены
импортировать как фича файлы в репозиторий…
а он должен по идее быть модулем к репозиторию с тестами…
Было у меня такой, только не с зефиром а XRAY, там есть возщможность выгружать сразу фьюче\стори файлы в ресурсы фрейморвка, и потом загружать репорт по этим кейсам.
1 лайк
Нет, виновата именно BDD болячка. В основе её вовсе не лень, а тот факт, что те проблемы, которые BDD призван решать - иллюзорны. BDD говорит: “Я позволю вам делать то-то и то-то!” - а никому это не надо.
А те, кому показалось, что надо, просто не разобрались, какая у них на самом деле проблема была. С помощью BDD они хотели вылечить не болезнь, а симптом.
3 лайка
Хотели чтобы все мэнуал QA могли писать тесты, а надо было лишь нанять хотябы мидла AQA))
1 лайк
А какие проблемы призван решить BDD? И что он обещает? Какая болезнь и какие симптомы?
Может лечение дорого/сложно/невозможно? А жить с болью не хочется и люди хотят снять хотя бы симптомы? 
Сейчас многие так с простудой на работу ходят. Выпил колдоекса, снял симптом и вперед, а выздоровление в фоновом режиме.
Нет, это явно не тот случай
Симптомы простуды можно снимать, потому что она и сама пройдёт, надо просто подождать. Но не стоит снимать (симптом простуды) насморк антибиотиками, потому что они точно не помогут, но с большой вероятностью ухудшат ситуацию.
Могу накидать несколько вариантов болезней/обещаний.
-
Что обещает BDD: красивые отчёты.
Какую проблему надеется решить менеджмент с помощью BDD: отсутствие доверия к команде. Непрозрачный рабочий процесс.
Решает ли BDD эту проблему: нет. Доверия как не было, так и нет. Красивые отчёты есть, но все же понимают, что при должном старании там можно нарисовать всё, что угодно. -
Что обещает BDD: красивые отчёты.
Какую проблему надеется решить менеджер с помощью BDD: Показать менеджеру высшего звена или заказчику, что “у нас всё круто”, работа кипит.
Какая проблема на самом деле: этот менеджер - промежуточный человек, ничего полезного в проект не привносит.
Решает ли BDD эту проблему: нет. Гнать таких в шею - вот решение. -
Что обещает BDD: тесты смогут писать даже нетехнические люди.
Какую проблему надеется решить менеджер с помощью BDD: Технарей мало, они всё не успевают. Хочется часть работы переложить на гуманитариев.
Решает ли BDD эту проблему: нет. Вся работа по поддержке степов и прочей БелиБерДы по-любому ложится на плечи технарей. Этой работы много, она сильно всё усложняет. Им было бы встоципот раз проще написать те же тесты самим без всяких аналитиков и геркина.
P.S. Кстати, толковых гуманитариев тоже мало. А нетолковые только мешают.
7 лайков
В моём понимании БДД решет не указанные Вами проблемы (ну или доложен решать) а вот эти:
- должен помочь бизнесу(ПО) проверить правильный ли результат он получит, если разработчики сделают его сценарий
- Обсудить и найти решение проблем которые становятся ясными после написания сценариев
- Собственно сформировать непротиворечивые требование хотя бы на уроне UX и логики
вопрос конечно если такие проекты где именно так и происходит…
Тестирование в по БДД сценариям собственно это просто часть подхода к разработке в целом.
Если заказчик не принимает работу по своим же сценариям и даже не пишет\ревьюит их
то это не БДД ИМХО
Это всё не про БДСМ этот, а про санитарный минимум для требований: что надо, для кого, как понять, что готово (DoD, Acceptance criteria), т.е. DoR для того, чтобы браться за историю.
Надо ли для этого человекочитаемые тесты? Нет…
1 лайк
Приятно когда разговор переходит в область конкретики. 
Андрей, с вашего развернутого комментария у меня сложилось впечатление, что у нас всё же разговор о разных вещах. Из ваших слов я отчетливо вижу проступающий BDD-фрейморк, возможно Cucumber или JBehave или Specflow, но не процесс разработки включающий постановку задачи, анализ, разработку, тестирование и приемку.
Я имею ввиду, что если брать только фрейморк и не брать процесс, то это действительно глупая и ненужная работа, и я ни в коем случае не призываю заниматься этой бессмыслицей, составлять регулярки и пыжиться, придумывая как передавать данные между шагами, обходить различные баги и т.д.
Если же по пунктам пройтись, то:
Во-первых, я не видел обещаний отчетов, но видел про “самоизвлекающуюся тестовую документацию”, а отчеты это скорее вотчина Allure, Report Portal’ов и иже с ними. По поводу проблемы - отсутствие доверия. Это довольно расплывчатая штука и мир пока не придумал никаких решений для данной проблемы и BDD тут не исключение. Если идти той же тропинкой, то и CodeReview это отсутствие доверия внутри команды и вообще процесс контроля качества и тестирования - это из-за отсутствия доверия к исполнителям… 
Цель и постулат BDD из того что я слышал - это привлечь к разработке безнес, т.е. сделать их частью процесса разработки и тем самым улучшить прозрачность и понимание данного процесса, а также увеличить степень доверия. Возможно, что я несколько идеализированно воспринимаю данные постулаты. В реальном мире сам не встречал подобной идиллии.
Во-вторых, снова отчеты… по-моему вы их не любите. Но, хороший отчет это способ сократить время на анализ и восприятие информации, вычленить всё важное и отсечь ненужное. В куске лога в Jenkins’е я тоже могу увидеть подробности выполнения пяти сотен/тысяч тестов, но почему-то мне намного проще и приятнее смотреть информацию в виде сводной таблицы в Allure. Отчеты ни в коем случае не враги разработчикам, более того, для многих из них это их источник заработка 
По поводу “лишних” людей на проектах - это очень болезненная тема. Особенно, в огромных компаниях. И тут не только менеджеры среднего звена, туда же можно включать смело и половину команды разработки и тестирования. Более того не все люди могут выдавать ежедневно 120% КПД. Обычно есть периоды повышенной продуктивности и спада. Интересно, как вы планируете “выгнать” начальника? Высшее звено управления летает в таких заоблачных далях, куда обычным смертным пути нет. А для команды именно “промежуточное звено” и становится их отправной точкой для работы и получения задач.
В-третьих, тут пожалуй соглашусь. Действительно есть такой тренд “писать тесты смогут даже гуманитарии”. По факту же, чтобы писать тесты на БДД, нужно правильно строить шаги и выбирать уровень абстракции. Я вообще очень часто вижу одну очень распространенную болячку БДД - попытка описать реализацию теста, а не описать желательное поведение системы без учета реализации или с минимумом раскрытия данной информации. Причем такой болячкой чаще страдают автоматизаторы, которых “заставляют” писать на BDD и они описывают свой тест. Как будто так и нужно было делать.
Но, к слову тренд про “написать могут даже гуманитарии” идет не только в BDD, он относится вообще к любому keyword-driven подходу, якобы они так круто и сильно всё упрощают, что можно взять 1-2 спецов пилить фрейморк и десяток студентов за полкило колбасы и они всё сделают не хуже маститого QA инженера. Но факт есть факт - технарей, действительно сильных и толковых - не так уж и много. Более того, даже такие люди всё еще допускают ошибки и если в Selenide это будет лишь небольшая неприятность и пара часов потраченного времени у пары десятков инженеров, то на других проектах это может быть путь в один конец. Провалы там просто недопустимы. И формализация процесса там играет уже большую роль, в этом случае BDD это уже не блажь, а попытка ограничить степень риска. Причем и он гарантий конечно же не дает.
Вот тут нашел несколько статей + ролик от людей, которые применяли BDD на своих проектах и оценивали этот опыт в основе своей позитивно:
- - YouTube
- Если у вас нет собаки… / Habr
- https://habr.com/company/luxoft/blog/150597/
- Автоматизация по методологии BDD. Наш опыт успешного внедрения / Habr
- Specification By Example – BDD для прагматиков / Habr
Есть и другие выступления, доклады и статьи. Статьи выше на русском, но BDD значительно больше популярен на западе и статей там по нему значительно больше.
Что я этим всем хотел сказать: я не защищаю BDD, он не нуждается в моей защите. Более того, я его у себя на проекте не применяю и не практикую. По понятным причинам Но я считаю, что вряд ли все перечисленные выше люди, которые делятся позитивным опытом работы в этой парадигме - нас обманывают или заблуждаются. Скорее всего у них действительно получились устраивающие их результаты, которые они не только почувствовали, но и посчитали в количественном выражении (ага, с помощью отчетов ). И скорее всего путь этот не был так прост как о нём говорят, а моя аналогия с мытьём клозета, я считаю как нельзя лучше отражает эту ситуацию. Кто-то моет хорошо и регулярно и результат виден, а кто-то спустя рукава и очень редко - как итог результат точно также быстро проявляется.
5 лайков
Чёрт, как позитивно!
Да, вы говорите о том, каким BDD должен быть по изначальной задумке. И да, мне сама по себе задумка очень нравится. Я хотел бы жить в мире, где это работает. Привлечь к разработке бизнес - это хорошая, правильная цель. Но да, это слишком идеализированно.
А я как раз и говорю о том, во что это выливается на практике. Люди понимают “BDD = отчёты”, бизнес в процессе не участвует (а тесты пишут всё те же автоматизаторы) и т.д.
P.S. Да, я не люблю отчёты. Не вообще любые отчёты, потому что обычный JUnit тоже генерирует отчёт, которого вполне достаточно, чтобы понять, почему тест упал. Я не люблю “слишком красивые отчёты”, которыми подменили изначальные идеи BDD.
5 лайков
Вот именно, как будто по отчетам из коробки невозможно понять от чего упал тест
1 лайк
Вообще-то bdd использует формат “given-when-then”, Который внутри себя может содержать подход keyword-driven. В чистом виде keyword-driven подход выживает только с использованием специализированных инструментах.
А по поводу BDD - проблема сообщества в том, что под BDD понимают именно подход разработки автотестов с формализацией требований в формате “given-when-then”.
1 лайк
BDD вообще-то - такой же подход к разработке, как и TDD. И этот подход, также как и TDD будет работать только тогда, когда его “готовят” правильно. Нельзя же называть TDD процесс, когда сначала пишут код, а потом тесты и сидят удивляются, что у них дизайн системы какой-то хреновый и вообще тесты писать долго и дорого. То же самое и с BDD. Под BDD тут называют автотесты, написанные в формате “givеn-when-then”, которые видимо пишет даже не команда, а выделенные для этой задачи люди. Которые вероятно даже не в контексте разрабатываемого продукта. И разработка происходит не снаружи внутрь. Что является ключевым условием в BDD. Сначала тесты - потом код.
И если уж следовать канонам, то надо понимать зачем команда ввязывается в историю с BDD. На моем опыте скажу, что данный подход взлетал только в тех командах, где инициатором выступал в первую очередь бизнес. У команда, практикующих данный подход, происходит ориентация на бизнес.
Во всех этих демагогиях описанных в этом треде, никто даже не упомянул про цикл "discover-formalization-automated-coding” на котором в принципе основывается BDD как подход к разработке.
1 лайк
Комон! Где написано, и кто сказал, что BDD обещает красивые отчеты? Вы серьезно?
Где BDD обещает, что тесты смогут писать нетехнические люди?
Это всего лишь домыслы, которые сообщество придумало, чтоб как-то продавать BDD своему руководству. Но это не BDD обещает. Давайте вещи называть своими именами.
1 лайк