BDD — спецификации на примере

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

Specification by Example — это совместный подход для определения требований и бизнес-ориентированных функциональных тестов для программных продуктов на основе сбора и иллюстрирования требований с использованием реалистичных примеров вместо абстрактных утверждений.

Спецификация на примере — Обзор

Цель «Спецификации на примере» заключается в том, чтобы сосредоточиться на разработке и предоставлении приоритетных, проверяемых бизнес-требований. Хотя сама по себе концепция «Спецификация путем примера» является относительно новой, она просто перефразирует существующие практики.

Он поддерживает очень конкретный, краткий словарь, известный как вездесущий язык, который —

• Включает исполняемые требования.

• Используется всеми в команде.

• Создан многофункциональной командой.

• Захватывает понимание каждого.

Включает исполняемые требования.

Используется всеми в команде.

Создан многофункциональной командой.

Захватывает понимание каждого.

Спецификация по Примеру может использоваться как прямой вход в построение Автоматизированных тестов, которые отражают бизнес-область. Таким образом, в центре внимания Specification by Example находится построение правильного продукта и построение правильного продукта.

Цель спецификации на примере

Основная цель Specification by Example — создать правильный продукт. Основное внимание уделяется общему пониманию, что создает единый источник истины. Это позволяет автоматизировать критерии приемки, поэтому основное внимание уделяется предотвращению дефектов, а не их обнаружению. Это также способствует раннему тестированию для выявления дефектов на ранней стадии.

Использование SbE

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

• Тестируется без перевода.

• Захвачено в живой документации.

Тестируется без перевода.

Захвачено в живой документации.

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

• Их легче понять.

• Их сложнее неправильно понять.

Их легче понять.

Их сложнее неправильно понять.

Преимущества SbE

Преимущества использования спецификации на примере —

• Повышенное качество

• Уменьшенные отходы

• Снижение риска производственных дефектов

• Сосредоточенное усилие

• Изменения могут быть сделаны более безопасно

• Улучшенное участие бизнеса

Повышенное качество

Уменьшенные отходы

Снижение риска производственных дефектов

Сосредоточенное усилие

Изменения могут быть сделаны более безопасно

Улучшенное участие бизнеса

Применение SbE

Спецификация на примере найти приложения в —

• Сложный бизнес или сложная организация.

• Не работает для чисто технических проблем.

• Не подходит для программных продуктов, ориентированных на пользовательский интерфейс.

• Может применяться и к устаревшим системам.

Сложный бизнес или сложная организация.

Не работает для чисто технических проблем.

Не подходит для программных продуктов, ориентированных на пользовательский интерфейс.

Может применяться и к устаревшим системам.

SbE и приемочные испытания

Преимущества Specification by Example с точки зрения приемочного тестирования:

• Одна единственная иллюстрация используется как для подробных требований, так и для тестирования.

• Прогресс проекта с точки зрения приемочных испытаний —

  • Каждый тест должен проверить поведение.

  • Тест либо проходит на поведение, либо нет.

  • Проходной тест показывает, что конкретное поведение завершено.

  • Если для проекта, требующего 100 вариантов поведения, выполнено 60 вариантов поведения, то он завершен на 60%.

• Тестеры переходят от устранения дефектов к предотвращению дефектов, и они вносят вклад в разработку решения.

• Автоматизация позволяет мгновенно понять влияние изменения требований на решение.

Одна единственная иллюстрация используется как для подробных требований, так и для тестирования.

Прогресс проекта с точки зрения приемочных испытаний —

Каждый тест должен проверить поведение.

Тест либо проходит на поведение, либо нет.

Проходной тест показывает, что конкретное поведение завершено.

Если для проекта, требующего 100 вариантов поведения, выполнено 60 вариантов поведения, то он завершен на 60%.

Тестеры переходят от устранения дефектов к предотвращению дефектов, и они вносят вклад в разработку решения.

Автоматизация позволяет мгновенно понять влияние изменения требований на решение.

Спецификация на примере — что это значит для разных ролей

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

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

Требования однозначны и не имеют функциональных пробелов.

Разработчики, на самом деле читают спецификации.

Разработчики лучше понимают, что разрабатывается.

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

Тестеры лучше понимают, что тестируется.

Тестеры участвуют с самого начала и играют определенную роль в дизайне.

Тестеры работают в направлении предотвращения дефектов, а не обнаружения дефектов.

Время экономится путем выявления ошибок с самого начала.

Качественный продукт производится с самого начала.

SbE — набор шаблонов процессов

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

Шаблоны процесса —

• Совместная спецификация

• Иллюстрируя спецификации, используя примеры

• Уточнение спецификации

• Примеры автоматизации

• Проверять часто

• Живая документация

Совместная спецификация

Иллюстрируя спецификации, используя примеры

Уточнение спецификации

Примеры автоматизации

Проверять часто

Живая документация

Совместная спецификация

Цели совместной спецификации:

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

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

• Обеспечить совместное общение и владение функциями.

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

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

Обеспечить совместное общение и владение функциями.

Эти цели достигаются в мастерской спецификаций, также известной как встреча трех амигосов. Три Amigos — BA, QA и разработчик. Хотя в проекте есть и другие роли, эти трое будут нести ответственность и отчитываться от определения до предоставления функций.

Во время встречи —

• Business Analyst (BA) представляет требования и тесты для новой функции.

• Три Amigos (BA, Developer и QA) обсуждают новую функцию и рассматривают спецификации.

• QA и разработчик также определяют отсутствующие требования.

• Три Амиго

  • Используйте общую модель, используя вездесущий язык.

  • Использовать словарь домена (при необходимости поддерживается глоссарий).

  • Ищите различия и конфликты.

• Не переходите к деталям реализации на этом этапе.

• Достигните консенсуса относительно того, была ли функция указана достаточно.

• Общее понимание требований и владение тестами облегчает качество спецификаций

• Требования представлены в виде сценариев, которые обеспечивают явные, однозначные требования. Сценарий является примером поведения системы с точки зрения пользователей.

Business Analyst (BA) представляет требования и тесты для новой функции.

Три Amigos (BA, Developer и QA) обсуждают новую функцию и рассматривают спецификации.

QA и разработчик также определяют отсутствующие требования.

Три Амиго

Используйте общую модель, используя вездесущий язык.

Использовать словарь домена (при необходимости поддерживается глоссарий).

Ищите различия и конфликты.

Не переходите к деталям реализации на этом этапе.

Достигните консенсуса относительно того, была ли функция указана достаточно.

Общее понимание требований и владение тестами облегчает качество спецификаций

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

Иллюстрирование спецификации с использованием примеров

Сценарии указываются с использованием структуры Given-When-Then для создания тестируемой спецификации —

Учитывая <некоторое предварительное условие>

И <дополнительные предварительные условия> Необязательно

Когда <действие / триггер происходит>

Тогда <какое-то почтовое условие>

И <дополнительные условия публикации> Необязательно

Эта спецификация является примером поведения системы. Он также представляет собой критерий приемлемости системы.

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

Уточнение спецификации

Чтобы уточнить спецификацию,

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

• Сосредоточьтесь на деловой перспективе и избегайте технических деталей.

• Учитывайте как положительные, так и отрицательные условия.

• Придерживайтесь предметной лексики.

• Обсудите примеры с заказчиком.

  • Выберите разговоры для достижения этой цели.

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

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

• Укажите дополнительные бизнес-правила, такие как сложные вычисления, обработка / преобразование данных и т. Д.

• Включите нефункциональные сценарии (например, производительность, нагрузка, удобство использования и т. Д.) В качестве спецификации на примере

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

Сосредоточьтесь на деловой перспективе и избегайте технических деталей.

Учитывайте как положительные, так и отрицательные условия.

Придерживайтесь предметной лексики.

Обсудите примеры с заказчиком.

Выберите разговоры для достижения этой цели.

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

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

Укажите дополнительные бизнес-правила, такие как сложные вычисления, обработка / преобразование данных и т. Д.

Включите нефункциональные сценарии (например, производительность, нагрузка, удобство использования и т. Д.) В качестве спецификации на примере

Примеры автоматизации

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

Выполните автоматизацию тестирования, используя домен-специфический язык (DSL), и покажите четкую связь между входами и выходами. Фокус на спецификации, а не на сценарии. Убедитесь, что тесты являются точными, простыми для понимания и тестируемыми.

Проверка часто

Включайте пример проверки в свой конвейер разработки при каждом изменении (добавление / изменение). Существует множество методов и инструментов, которые можно (и нужно) применять для обеспечения качества продукта. Они основаны на трех ключевых принципах: « Тестируй рано», «Тестируй хорошо» и « Тестируй часто» .

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

Живая Документация

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

Спецификация на примере шагов процесса

На рисунке показаны этапы процесса в Спецификации по Примеру.

Анти-паттерны

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

Анти-паттерны порождают различные проблемы.

Анти-шаблон	Проблемы
Нет сотрудничества	Много предположений Строить неправильную вещь Тестирование неправильной вещи Не знаю, когда код закончен
Не знаю, когда код закончен	Трудно поддерживать тесты Трудно понять спецификацию Потеря интереса со стороны представителей бизнеса
Слишком подробные или слишком ориентированные на интерфейс примеры	Трудно поддерживать тесты Трудно понять спецификации Потеря интереса со стороны представителей бизнеса
Требуется недооценка усилий	Команды считают, что потерпели неудачу и разочаровываются рано

Много предположений

Строить неправильную вещь

Тестирование неправильной вещи

Не знаю, когда код закончен

Трудно поддерживать тесты

Трудно понять спецификацию

Потеря интереса со стороны представителей бизнеса

Трудно поддерживать тесты

Трудно понять спецификации

Потеря интереса со стороны представителей бизнеса

Команды считают, что потерпели неудачу и разочаровываются рано

Решение проблем — качество

Качество можно обеспечить, следя за анти-шаблонами. Чтобы минимизировать проблемы, создаваемые анти-шаблонами, вы должны:

• Собирайтесь, чтобы уточнить, используя примеры.

• Очистить и улучшить примеры.

• Напишите код, который удовлетворяет примерам

• Автоматизируйте примеры и разверните.

• Повторите подход для каждой пользовательской истории.

Собирайтесь, чтобы уточнить, используя примеры.

Очистить и улучшить примеры.

Напишите код, который удовлетворяет примерам

Автоматизируйте примеры и разверните.

Повторите подход для каждой пользовательской истории.

Чтобы решить проблемы из-за анти-шаблонов означает соблюдение —

• Сотрудничество.

• Сосредоточиться на чем.

• Ориентация на бизнес.

• Будь готов.

Сотрудничество.

Сосредоточиться на чем.

Ориентация на бизнес.

Будь готов.

Давайте поймем, что означает каждый из вышеперечисленных.

сотрудничество

В сотрудничестве —

• Деловые люди, разработчики и тестировщики вносят свой вклад со своей точки зрения.

• Автоматизированные примеры доказывают, что команда построила правильную вещь.

• Процесс ценнее самих тестов.

Деловые люди, разработчики и тестировщики вносят свой вклад со своей точки зрения.

Автоматизированные примеры доказывают, что команда построила правильную вещь.

Процесс ценнее самих тестов.

Сосредоточение на чем

Вы должны сосредоточиться на вопросе — «что». Сосредоточив внимание на «что» —

• Не пытайтесь охватить все возможные случаи.

• Не забудьте использовать разные виды тестов.

• Приведите примеры как можно проще.

• Примеры должны быть легко понятны пользователям системы.

• Инструменты не должны играть важную роль в мастерских.

Не пытайтесь охватить все возможные случаи.

Не забудьте использовать разные виды тестов.

Приведите примеры как можно проще.

Примеры должны быть легко понятны пользователям системы.

Инструменты не должны играть важную роль в мастерских.

Сосредоточиться на бизнесе

Сосредоточиться на бизнесе —

• Держите спецификацию в деловых целях.

• Включите бизнес в создание и просмотр спецификаций.

• Скрыть все детали в слое автоматизации.

Держите спецификацию в деловых целях.

Включите бизнес в создание и просмотр спецификаций.

Скрыть все детали в слое автоматизации.

Будь готов

Будьте готовы к следующему —

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

• Представить SbE сложно.

• Требует времени и вложений.

• Автоматическое тестирование не приходит бесплатно.

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

Представить SbE сложно.

Требует времени и вложений.

Автоматическое тестирование не приходит бесплатно.

инструменты

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

Следующие инструменты поддерживают Specification by Example —

Огурец

SpecFlow

Fitnesse

JBehave

Concordion

Behat

жасмин

смаковать

Speclog