BDD: напишите лучшие сценарии. Если вы практиковали Agile… | by Biswajit Pattanayak

Photo by Margarida CSilva on Unsplash

Если вы практиковали Agile-разработку программного обеспечения, вы слышали о значительных изменениях в BDD. Разработка программного обеспечения — это совместный процесс, и команды должны постоянно взаимодействовать друг с другом, чтобы избежать недопонимания, связанного с разрабатываемым программным обеспечением. Поскольку поставки программного обеспечения включают как технических, так и нетехнических специалистов, крайне важно создать общую структуру или язык для написания требований, и BDD помогает нам в этом. Вы, вероятно, найдете лучшее объяснение BDD на Сайт Дэна Норта ; однако, если вы либо уже читали его, либо слишком взволнованы, чтобы не оставить мой пост между ними, вот краткое объяснение процесса.

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

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

В этом посте рассказывается о антипаттернах, наблюдаемых при написании спецификаций, и о том, как мы можем их избежать. Чтобы понять это, давайте определим еще несколько терминов из экосистемы BDD — Gherkin и Cucumber (или аналогичные инструменты BDD, такие как Behave, JBehave и т. д.)

человекочитаемый формат. Мы можем определить наши критерии приемлемости для пользовательской истории (наиболее атомарная форма требования) в формате Gherkin.

Инструменты BDD, такие как Cucumber , представляют собой платформы, которые анализируют синтаксис Gherkin для создания тестов автоматизации. Разработчики могут написать реализацию тестов, чтобы запускать их против тестируемого приложения (AUT). Давайте посмотрим на пример, чтобы понять концепцию.

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

 Сценарий: товары в корзине на кассе Учитывая, что книга "Чудеса всех времен" стоит 20 долларов 
 И Оливия добавила книгу в свою корзину 
 Когда она проверяет корзину 
 Затем книга указана в последней кассе 
 И общая стоимость корзины составляет 20 долларов США 

И огурец проанализирует спецификацию функции, чтобы сгенерировать реализацию следующего шага.

Так красиво и свежо!!! Эта простота огурца (а также других инструментов BDD) побудила QA написать приемочные тесты в формате корнишона. Cucumber имеет очень хорошую интеграцию с библиотеками автоматизации или инструментами, такими как селен, которые помогают тестировщикам писать автоматические тесты для своих регрессионных наборов. И здесь мы видим довольно много антипаттернов, которые угрожают дестабилизировать процесс сотрудничества, если их не исправить в самом начале. Обсуждаемые ниже антишаблоны не являются исчерпывающими; однако они представляют собой основные из них. Если вы столкнулись с шаблонами, которых нет в списке ниже, оставьте свои комментарии, и я включу их в пост.

1. BDD как процедурный подход приводит к ухудшению читаемости и накладным расходам на обслуживание

 Сценарий: товары в корзине на кассе Учитывая, что книга «Чудеса на все времена» стоит 20 долларов 
 И Оливия вводит название книги в поле поиска 
 И она выбирает книга из результатов поиска 
 Когда она нажимает кнопку «добавить в корзину» 
 И нажимает кнопку корзины 
 Затем появляется экран проверки корзины 
 И книга указана в окончательной кассе 
 И общая стоимость корзины составляет 20 долларов США 

Сценарий должен быть связан с тем, что, а не как. Здесь шаг добавления товара в корзину слишком детализирован, что делает шаги раздутыми. Вполне возможно, что в будущем способ взаимодействия с приложением для добавления товара в корзину может измениться. Мы можем просто перейти от выбора по клику к выбору с помощью голосового управления. В таком случае некоторые шаги могут быть неприменимы. Поэтому сценарий должен быть написан на высоком уровне, описывающем поведение системы, а не каждое подробное действие, которое пользователь должен будет выполнить, чтобы использовать систему. Действия следует подтолкнуть к реализации.

2. Свободное (аб)использование синтаксиса корнишонов

 Сценарий: товары в корзине на кассе Учитывая, что книга «Чудеса всех времен» стоит 20 долларов 
 Когда Оливия добавила книгу в корзину 
 Затем она проверяет корзину 
 И книга указана на последней кассе 
 Тогда общая стоимость тележки составляет 20 долларов 

Ключевые слова в синтаксисе корнишонов имеют значение, и мы должны уважать это. Вот что они должны передать.

• Дано — установить предусловие или контекст
• Когда — совершить действие
• Тогда — проверить результат действия
• И, Но — следует использовать вместе с Дано, Когда или Тогда

3. Не делая намерения ясности сценария

 Сценарий: <  можете ли вы выяснить цель сценария  ;  Я не мог  >Учитывая, что книга "Чудеса на все времена" стоит 20 долларов 
 Когда Оливия ищет книгу 
 Тогда книга отображается в соответствующих результатах поиска 
 Когда она выбирает книгу 
 Затем книга добавляется в корзину 
 Когда она проверяет корзину 
 Затем книга отображается в последней кассе 
 И общая стоимость корзины составляет 20 долларов 

Не очень ясно из примера, что сценарий должен достичь. Проверяет ли это функцию поиска, можно ли добавить искомый товар в корзину или отображаются ли в корзине выбранные товары?

4.

Подробнее; еще больше путаницы

 Сценарий: товары в корзине на кассе Учитывая стоимость книги "Чудеса на все времена" $20 
 И книга есть в наличии 
 И Оливия добавила книгу в свою корзину 
 Когда она проверяет корзину 
 И она просматривает информацию о корзине 
 Затем книга отображается в последней кассе 
 И общая стоимость корзины составляет $20 

Шаги « книга есть на складе » и « она просматривает детали корзины » не имеют особого отношения к масштабу сценария. Если нам действительно нужно проверить, есть ли книга в наличии, это может быть отдельный сценарий. Шаг она просматривает детали тележки ’ слишком двусмысленно. Хотя в этом примере было легко заметить избыточный шаг, в реальной жизни это может быть довольно сложно.

5. Верхний тяжелый сценарий

 Сценарий: проверка суммы к оплате при размещении заказаУчитывая, что я захожу на сайт покупок 
 И я покупаю книгу bdd стоимостью 200 сингапурских долларов 
 И книга продается со скидкой 20% 
 При навигации на страницу оформления заказа 
 И я проверяю общую сумму к оплате 
 Затем я вижу сумму как 160 сингапурских долларов 

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

6. Сценарии ошибок и пограничные случаи как BDD

 Сценарий: страница проверки корзины, когда истекает время запроса. Учитывая, что книга «Чудеса на все времена» стоит 20 долларов США 
 И Оливия добавила книгу в свою корзину 
 Когда она проверяет корзину 
 И время ожидания ответа истекло 
 Затем отображается сообщение об ошибке "время ожидания истекло" 
 И книга не указана в окончательной кассе 

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

Рекомендации, которым следует следовать при написании сценариев BDD

Теперь, когда мы увидели часто встречающиеся антишаблоны, давайте разберемся, как применять КРАТКОЕ ОПИСАНИЕ Философия может помочь нам написать более читаемые и удобные для сопровождения примеры BDD.

• Использование делового языка для выражения намерений — использование деловой терминологии может сократить разрыв между техническими и нетехническими заинтересованными сторонами в команде
• Использование реальных данных, чтобы избежать забытых требований — , когда команда работает в режиме реального времени варианты использования, чтобы понять поведение, шансы упустить крайние случаи или скрытую информацию снижаются
• Раскрыть намерение, а не реализацию — Описание шагов должно быть мало техническим. Они должны больше говорить о том, что система делает, а не о том, как она это делает.
• Сохранить только Essentials — избегать загромождения сценария нерелевантными шагами, чтобы сделать его достаточно интересным для всех тест детерминистический. Мы можем запихнуть все возможности в сценарий ручного тестирования (хотя я бы не рекомендовал этого делать), но автоматические тесты не должны иметь дело с условиями if else при проверке результатов.