Как выучить / научить корнишон для огурца


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

Я прочитал некоторые основные сведения на сайте GitHub для Cucumber и от быстрого поиска Google, но хотел бы знать, есть ли рекомендуемые ресурсы для получения нетехнических людей, чтобы иметь возможность писать полный BDD с использованием корнишона (я предполагаю, что это предпочтительный язык для тестов Cucumber, которые будут созданы в).

Спасибо.

7 24

7 ответов:

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

Затем я привел им простой пример и сказал, чтобы они записали свои собственные черты так, как, по их мнению, они должны быть записаны. Удивительно, но структура была понятна сама по себе, и особенности, которые они написали стало отличным началом.
Единственной большой проблемой было то, что они содержали много логики в каждом шаге сценария. Я решил эту проблему, последовательно задавая вопрос: "почему?"что в большинстве случаев выявило основную функциональность, которую они искали, и мы переписали сценарии соответственно. Давая им рекомендации и позволяя самим писать статьи, они пачкали руки и были вынуждены думать о том, что они написали. Сегодня у них есть гораздо лучшее понимание и "почему?" итерации уже не так распространены. Конечно, вам нужно, чтобы бизнес-аналитики и разработчики работали в тесном сотрудничестве, и функции, которые пишут аналитики, должны действовать только как начало. Помните, что функции Cucumber-это просто общий язык между аналитиками и разработчиками. Им все еще нужно часто сидеть вместе, чтобы иметь возможность говорить друг с другом:)

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

Я могу ошибаться, но из вашего вопроса у меня складывается впечатление, что вы хотите обучить своих BAs писать Gherkin; затем они напишут кучу функций и передадут их разработчикам.

Это определенно не тот путь. Гораздо лучше, чтобы разработчики и пользователи BA (если это возможно) работали вместе, чтобы написать ваш сценарии и стройте их по ходу дела. Тогда вы все вместе узнаете, что работает, а что нет.

Мы попытались заставить БА написать целые функции и передать их. Мы (разработчики) в конечном итоге были вынуждены делать крупные переписывания, потому что реализация оказалась отличной от той, которую первоначально предполагал БА. Нам также пришлось изменить синтаксис шагов и сделать поиск и замену через весь файл.

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

С точки зрения того, как писать шаги, лучше всего начать с тех, которые поставляются с Cucumber, и скопировать и адаптировать их по мере работы над проектом, чтобы соответствовать вашему конкретному приложению. Нет ни правильного, ни неправильного, это то, что работает для вас. Документация на сайтах cucumber, как правило, хороша и будет ценным ресурсом, когда вы узнаете больше.

Мы учим корнишона (для SpecFlow) аналогично тому, как описал его mrD.

Я думаю, что это очень важно, хотя, что аудитория знакома с основным намерением "спецификации на примере", гибкого анализа требований и BDD, поэтому мы обычно начинаем обсуждать фон в первую очередь. Мы также покажем пример сценария корнишона и объясним самые основы (например, данные/когда/тогда/но и таблицы).

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

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

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

Хотя я никогда не знаю заранее, что произойдет, обычно это упражнение является лучшей частью нашего обучения BDD.

В книге RSpec есть пара глав, которые имеют отношение к бизнес-аналитикам:
http://pragprog.com/book/achbd/the-rspec-book

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

Хотя важно начать с написания первых сценариев, вам также нужны некоторые ресурсы, чтобы установить хорошие привычки и понять ключевые практики. Я написал книгу, которая могла бы помочь. "написание отличных спецификаций" это, я надеюсь, хороший способ узнать корнишон и огурец. Она охватывает паттерны и антипаттерны, а также ключевые техники для написания отличных сценариев. :) Если у вас есть какие-либо вопросы, вы всегда можете связаться со мной в Твиттере.

Если вы заинтересованы в покупке "написание отличных спецификаций", вы можете сэкономить 39% с промо-кодом 39nicieja2 :)

Другие большие ресурсы:

  • "Спецификация на примере" Гойко Адзича, если вас интересуют процессы разработки программного обеспечения и инженерные практики высокого уровня.
  • " БДД в действии " Джона Смарта, если вы не против прочитать тестовый код на Java. Это всеобъемлющий сквозной взгляд на определение и тестирование требований к программному обеспечению.
  • "поведенческая разработка" Лиз Кеог, если автоматизированное тестирование не вызывает сомнений, но вы хотите понять, как спецификации с примерами влияют на процессы бизнес-анализа.
  • "книга огурца: поведенческая разработка для тестировщиков и разработчиков" Мэтта Уинна и Аслака Хеллесея
  • " The Rspec Book: Behavior-Driven Development with RSpec, Cucumber, and Friends " by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North