Как выучить / приучить Корнишон к Огурцу

StackOverflow https://stackoverflow.com/questions/1704641

Вопрос

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

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

Спасибо.

Это было полезно?

Решение

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

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

Давая им рекомендации и позволяя им самим писать функции, они пачкали руки и были вынуждены думать о том, что они написали.Сегодня у них гораздо лучшее понимание, и повторения "почему?" уже не так распространены.

Конечно, вам нужно, чтобы бизнес-аналитики и разработчики тесно сотрудничали друг с другом, а функции, которые пишут аналитики, должны служить только началом.Помните, что функции Cucumber - это всего лишь общий язык между аналитиками и разработчиками.Им все еще нужно часто сидеть вместе, чтобы иметь возможность разговаривать друг с другом :)

Другие советы

http://cukes.info это отличный ресурс для обучения людей тому, как их писать. Бен Мейби также сделал отличную презентацию о Cucumber на конференции Mountain West Ruby 2009.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы заинтересованы в покупке “Writing Great Specifications”, вы можете сэкономить 39% с помощью промо-кода 39ничьежа2 :)

Другие замечательные ресурсы:

  • “Спецификация на примере” Гойко Адзича, если вы интересуетесь процессами разработки программного обеспечения и высокоуровневыми инженерными практиками.
  • “BDD в действии” Джона Смарта, если вы не против почитать тестовый код на Java.Это всеобъемлющий комплексный подход к определению и тестированию требований к программному обеспечению.
  • “Разработка, основанная на поведении” Лиз Киф, если автоматическое тестирование ни о чем не говорит, но вы хотите понять, как спецификации с примерами влияют на процессы вашего бизнес-анализа.
  • “Книга об огурцах:Поведенческая разработка для тестировщиков и разработчиков” Мэтта Уинна и Аслака Хеллесоя
  • “Книга RSpec:Поведенческое развитие с RSpec, Cucumber и друзьями” Дэвида Челимски, Дейва Астелса, Зака Денниса, Аслака Хеллесея, Брайана Хелмкампа, Дэна Норта
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top