Действительно ли BDD доступен для записи непрограммистам?


24

Разработка, основанная на поведении, с ее символическим синтаксисом сценариев «задано, когда», в последнее время получила широкое распространение из-за его возможного использования в качестве граничного объекта для оценки функциональности программного обеспечения.

Я , безусловно , согласен , что Огурец , или какой бы ни функция определения сценария вы предпочитаете, является бизнес - читаемый DSL , и уже обеспечивает значение как таковое.

Однако я не согласен с тем, что он доступен для записи непрограммистам (как это делает Мартин Фаулер ).

Есть ли у кого-нибудь отчеты о сценариях, которые пишут не программисты, а затем инструктируют разработчики?

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

Обновление: что касается инструмента «генератор сценариев», он, конечно, не будет магически угадывать бизнес-язык;) Но, так же, как в настоящее время мы используем сопоставители регулярных выражений для создания тестов в нисходящем подходе (в отношении абстракции), мы могли бы использовать строители строк для создания сценариев в подходе снизу вверх.

Пример «дать только идею»:

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

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

По иронии судьбы, JBehave 1 (первый инструмент BDD) начал с создания бизнес-читаемых сценариев. Мы не разбирали английский до огурца. Я думаю, что JBehave 1 был полезен для напоминания людям о том, что они должны сначала поговорить о них ...
Lunivore

Ответы:


20

Я видел это. Не закончилось хорошо.

Я думаю, что огурец является громоздкой (<- lol: D) абстракцией именно по этой причине. Слишком сложно для нетехнических людей писать самим; слишком многословен для технических людей.

Нетехнические люди просто не научились думать как программисты. Мы имеем привилегию понимать абстрактное знание, разбивать его, строить заново и все же быть в состоянии успешно избежать неоднозначности. Это то, за что нам платят.

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

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


20
Non technical people just haven't learned to think like programmers. Правда. Эта та же самая концепция была раскручена и заново изобретена несколько раз за последние 20 лет, и она почти всегда приводит к плохим результатам. Предприятиям нравится концепция получения программного обеспечения без необходимости платить этим жадным до крови пиявкам разработчикам программного обеспечения, но они забывают, что самая сложная часть разработки программного обеспечения - это в большинстве случаев понимание бизнес-правил глубже и сложнее, чем самим бизнесменам.
maple_shaft

2
«Нетехнические люди просто не научились думать, как программисты». Да, способность разлагать проблемы и выражать их в определенных атомарных логических терминах, вероятно, делает человека программистом / аналитиком. Мысль о том, что похожий на английский язык делает корнишон пригодным для использования любым человеком, кажется мне невероятно наивной. Спасибо за подтверждение :) Computer knows nothing about business domain.Конечно. Я не очень ясно изложил свою идею, извините за это. Я добавлю информацию к вопросу.
MattiSG

8
@maple_shaft: последние 20 лет? Попробуйте последние 60 лет. Некоторые из ранней ажиотажа вокруг COBOL заключались в том, что деловые люди могли писать это, устраняя необходимость в программистах. Когда этого не произошло, люди придумали несколько языков, которые они называли языками четвертого поколения, которые должны были делать то же самое.
Дэвид Торнли

11

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

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

Итак, достаточно «отношений с клиентами для программистов». Вопрос заключается в том, имеет ли еще смысл, чтобы клиент использовал читаемый бизнес DSL, чтобы определить, как определить спецификацию. Я полагаю, что с руководством ответ является предварительным «да», и я говорю предварительный, потому что следующий вопрос, который приходит на ум, - зачем вам заказчик создавать DSL, если у вас может быть программист, который легче определит тот, который будет предоставить клиенту простой, но богатый язык, чтобы определить, как система должна работать?

Когда вы предоставите клиенту язык для описания того, как он хотел бы, чтобы система работала, вы получите в итоге утверждения, которые говорят что-то вроде:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

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

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Опять очень четкие описания, на этот раз о том, каксистема должна вести себя Дело в том, что это не заменит необходимость для разработчика программного обеспечения заполнить все пробелы и выявить дополнительные детали, о которых клиент может знать только на периферии. В то время как клиент может быть «обучен» программистом описывать функции и поведение в удобном для программиста формате, у клиента не будет ни навыков, ни знаний для создания значимых тестовых случаев, ни для обеспечения реализации. код. Это было, я думаю, смысл статьи Мартина Фаулера, на которую ссылался ФП. Так что да, само программное обеспечение не доступно для записи клиенту, но описание программного обеспечения, безусловно, может - и ИМХО должно - быть написано клиентом. Что бы это ни стоило, я не читал статью Фаулера о том, что клиент не должен

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

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

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


«Чтобы протестировать сценарий, вы должны его понять, поэтому сценарий должен уже существовать, чтобы вы оба определили тест для него». Я согласен. Я спрашиваю, стоит ли что-либо для соблюдения языковых ограничений. Я не утверждаю, что мы должны писать только тесты; но мне интересно, не должны ли мы принять тот факт, что описание бизнеса будет (и, вероятно, должно) всегда быть простым описанием в свободной форме . Следовательно, у нас были бы чисто рабочие столы и генерируемые читаемые сценарии, позволяющие людям решать, соответствуют ли они; вместо того, чтобы притворяться, мы используем реальные тесты для проверки.
MattiSG

@MattiSG ...whether enforcing language constraints is worth anything. Это хороший вопрос. Описания в свободной форме более выразительны и естественны для автора, но приводят к бессвязным комментариям, которые требуют разбора, чтобы получить полезную спецификацию. Определяя формальные «правила» (иначе говоря, DSL) для написания требований и спецификаций, вы получаете общий язык, который понимают и клиент, и программист, ограничивая недопонимание. Если вы правильно поняли описания, они могут использоваться дословно в качестве шаблона для ваших тестов. Таким образом, нет необходимости в сложных инструментах для «генерации» чего-либо.
С.Робинс

@MattiSG FWIW, использование DSL и BDD - это система, которую я сам использую. Требования определяются как операторы Entity-Feature-Benefit и сопровождаются спецификацией, которая расширяет исходные операторы требований, используя операторы AAA (то есть: Given-When-Then) ... по сути, операторы сценариев. Сложность при попытке декодирования произвольного текста заключается в том, что без DSL у вас нет простого способа определить алгоритм, который может генерировать значимые сценарии сбора. Моя точка зрения заключалась в том, что использование тестов в качестве отправной точки для генерации сценариев является своего рода задом наперед.
С.Робинс

5

Я видел, как разработчики пишут сценарии; тестеры пишут сценарии, и даже владелец продукта пишет сценарии. У меня также были разговоры, явно предназначенные для выявления сценариев: «Учитывая <этот другой контекст>, когда что тогда произойдет?» - и записал слова, используемые бизнесом.

Наилучшие результаты у меня были от разговора с владельцем продукта, когда он был в офисе, захват их в вики, а затем отправка их ему, чтобы он мог исправить и добавить больше. Он нашел пару, которую мы пропустили в наших разговорах. Это потрясло.

Худшие сценарии, которые я видел, это те, которые разработчики написали сами, без какого-либо разговора с бизнесом. Я могу сказать, потому что они используют такие термины, как «Когда я выполняю поиск» или «Когда я отправляю форму с датой сегодня + 3». Как правило, это не очень интересные сценарии, их слишком много, слишком низкий уровень детализации и, следовательно, они абсолютно недостижимы. Бизнес также не читает это.

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


+1 Общение на самом деле является ключом, и сценарии действительно должны быть в терминах, которые используют деловые люди, поэтому в соответствии с вопросом OPs, если мы создаем DSL, это действительно должно быть в состоянии быть ближе. на то, что собирается сказать клиент, а не на то, что, по мнению программистов, должен сказать клиент.
С.Робинс

0

Мой опыт показывает, что лучше всего БА (бизнес-аналитик) написать GWT ( Given-When-Then ) s (опыт использования SpecFlow). БА может перевести требования клиента в GWT, и бизнес может прочитать его. Клиенты понимают системы, но у них нет технических идей, чтобы написать требования таким образом, чтобы мы могли их использовать.

В идеале БА должен был написать немного GWT, я бы сделал несколько пересмотров, БА пересмотрел бы / пересмотрел бы повтор, пока БА и бизнес не будут уверены в покрытии. Практически БА дал бы мне черновой набросок, который я бы очистил и сделал работу. Бизнес отмахивается от этого, говоря наверняка, а потом удивляется, почему он не охватывает некоторые области, о которых никто не задумывался.


Не могли бы вы объяснить, что для вас значит GWT ? :)
MattiSG

@ MattiSG: думаю, что это для заданного, когда-то (см. ОП).
Слёске

@MattiSG - Обновлен пост хороший улов.
SoylentGray
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.