BDD - Технические характеристики на примере
По словам Гойко Аджича, автора «Спецификации на примере», Спецификация на примере - это набор шаблонов процессов, которые облегчают изменение программных продуктов, чтобы гарантировать, что правильный продукт будет доставлен эффективно ».
Спецификация на примере - это совместный подход к определению требований и бизнес-ориентированных функциональных тестов для программных продуктов, основанный на регистрации и иллюстрации требований с использованием реалистичных примеров вместо абстрактных утверждений.
Спецификация на примере - Обзор
Задача Спецификации на примере - сосредоточиться на разработке и доставке приоритетных, проверяемых бизнес-требований. Хотя сама по себе концепция спецификации на примере относительно нова, это просто перефразирование существующих практик.
Он поддерживает очень конкретный краткий словарь, известный как вездесущий язык, который:
Включает исполняемые требования.
Используется всеми в команде.
Создан кросс-функциональной командой.
Улавливает понимание каждого.
Спецификация на примере может использоваться в качестве прямого ввода в построение автоматических тестов, отражающих бизнес-область. Таким образом, в «Спецификации на примере» основное внимание уделяется созданию правильного продукта и созданию правильного продукта.
Цель спецификации на примере
Основная цель «Спецификации на примере» - создать правильный продукт. Он фокусируется на общем понимании, тем самым устанавливая единый источник истины. Это позволяет автоматизировать критерии приемки, так что основное внимание уделяется предотвращению дефектов, а не обнаружению дефектов. Это также способствует раннему тестированию для раннего обнаружения дефектов.
Использование SbE
Спецификация на примере используется для иллюстрации ожидаемого поведения системы, описывающего ценность для бизнеса. Иллюстрация приводится с помощью конкретных примеров из реальной жизни. Эти примеры используются для создания исполняемых требований, которые:
Тестируется без перевода.
Записано в живой документации.
Ниже приведены причины, по которым мы используем примеры для описания конкретных спецификаций.
Их легче понять.
Их труднее неверно истолковать.
Преимущества SbE
Преимущества использования Спецификации на примере:
Повышенное качество
Сокращение отходов
Сниженный риск производственных дефектов
Сосредоточенные усилия
Изменения можно вносить более безопасно
Повышение вовлеченности бизнеса
Приложения SbE
Спецификация на примере найти приложения в -
Либо сложный бизнес, либо сложная организация.
Не подходит для чисто технических проблем.
Не работает для программных продуктов, ориентированных на пользовательский интерфейс.
Может применяться и к устаревшим системам.
SbE и приемочные испытания
Преимущества спецификации на примере с точки зрения приемочных испытаний:
Одна иллюстрация используется как для подробных требований, так и для тестирования.
Прогресс проекта в части приемочных испытаний -
Каждый тест предназначен для проверки поведения.
Тест либо проходит успешно, либо нет.
Прохождение теста означает, что определенное поведение выполнено.
Если в проекте, требующем выполнения 100 вариантов поведения, выполнено 60 вариантов поведения, то он завершен на 60%.
Тестировщики переключаются с исправления дефектов на предотвращение дефектов и вносят свой вклад в разработку решения.
Автоматизация позволяет мгновенно понять влияние изменения требований на решение.
Уточнение на примере - что это значит для разных ролей
Задача «Спецификации на примере» - способствовать сотрудничеству всех членов команды, включая клиента, на протяжении всего проекта для создания ценности для бизнеса. Все для лучшего понимания используют один и тот же словарь.
| Роль | Использование SbE |
|---|---|
| Бизнес-аналитик |
|
| Разработчик |
|
| Тестер |
|
| Все |
|
SbE - Набор шаблонов процессов
Как мы видели в начале этой главы, «Спецификация на примере» определяется как набор шаблонов процессов, которые способствуют внесению изменений в программные продукты, чтобы гарантировать эффективную поставку нужного продукта.
Шаблоны процесса -
Совместная спецификация
Иллюстрирование спецификаций на примерах
Уточнение спецификации
Примеры автоматизации
Часто проверять
Живая документация
Совместная спецификация
Цели совместной спецификации:
Получите различные роли в команде, чтобы иметь общее понимание и общий словарный запас.
Вовлеките всех в проект, чтобы они могли поделиться своими взглядами на ту или иную функцию.
Обеспечьте совместное общение и владение функциями.
Эти цели достигаются на семинаре по спецификациям, также известном как встреча трех сторонников. Три Amigos - это BA, QA и разработчик. Хотя в проекте есть и другие роли, эти трое будут нести ответственность и подотчетны от определения до предоставления функций.
During the meeting −
Бизнес-аналитик (BA) представляет требования и тесты для новой функции.
Три Amigos (BA, Developer и QA) обсуждают новую функцию и рассматривают спецификации.
QA и разработчик также определяют недостающие требования.
Три Амигоса
Используйте общую модель, используя повсеместный язык.
Используйте словарь предметной области (при необходимости ведется глоссарий).
Ищите различия и конфликты.
Не переходите к деталям реализации на этом этапе.
Достигните консенсуса относительно того, достаточно ли указана функция.
Общее понимание требований и владение тестами способствуют разработке требований к качеству
Требования представлены в виде сценариев, которые содержат явные и недвусмысленные требования. Сценарий - это пример поведения системы с точки зрения пользователей.
Иллюстрация спецификации на примерах
Сценарии указываются с использованием структуры Given-When-Then для создания проверяемой спецификации -
Given <некоторое предварительное условие>
And <дополнительные условия> Optional
When <происходит действие / триггер>
Then <какое-то условие публикации>
And <дополнительные условия публикации> Optional
Эта спецификация является примером поведения системы. Он также представляет собой критерий приемлемости системы.
Команда обсуждает примеры, и отзывы учитываются до тех пор, пока не будет достигнуто соглашение о том, что примеры охватывают ожидаемое поведение функции. Это обеспечивает хорошее тестовое покрытие.
Уточнение спецификации
Чтобы уточнить спецификацию,
Будьте точны при написании примеров. Если пример оказывается сложным, разбейте его на более простые примеры.
Сосредоточьтесь на деловой перспективе и избегайте технических деталей.
Учитывайте как положительные, так и отрицательные условия.
Придерживайтесь лексики предметной области.
Обсудите примеры с заказчиком.
Выберите разговоры, чтобы добиться этого.
Учитывайте только те примеры, которые интересны заказчику. Это позволяет создавать только требуемый код и позволяет избежать охвата всех возможных комбинаций, которые могут не потребоваться.
Чтобы гарантировать, что сценарий проходит, все тестовые примеры для этого сценария должны пройти. Следовательно, улучшите спецификации, чтобы сделать их тестируемыми. Тестовые примеры могут включать в себя различные диапазоны и значения данных (граничные и угловые случаи), а также различные бизнес-правила, приводящие к изменениям данных.
Укажите дополнительные бизнес-правила, такие как сложные вычисления, обработка / преобразование данных и т. Д.
Включите нефункциональные сценарии (например, производительность, нагрузка, удобство использования и т. Д.) В качестве спецификации на примере
Примеры автоматизации
Уровень автоматизации должен быть очень простым - просто подключите спецификацию к тестируемой системе. Вы можете использовать инструмент для того же.
Выполните автоматизацию тестирования с использованием предметно-ориентированного языка (DSL) и покажите четкую связь между входами и выходами. Сосредоточьтесь на спецификации, а не на сценарии. Убедитесь, что тесты точны, понятны и поддаются тестированию.
Часто проверять
Включите пример проверки в конвейер разработки при каждом изменении (добавлении / модификации). Существует множество методов и инструментов, которые можно (и нужно) использовать, чтобы гарантировать качество продукта. Они вращаются вокруг трех ключевых принципов:Test Early, Test Well и Test Often.
Часто выполняйте тесты, чтобы выявлять слабые звенья. Примеры, представляющие поведение, помогают отслеживать прогресс, и поведение считается завершенным только после прохождения соответствующего теста.
Живая документация
Делайте спецификации как можно более простыми и короткими. Организуйте спецификации и развивайте их по мере выполнения работы. Сделайте документацию доступной для всех в команде.
Спецификация на примерах этапов процесса
На иллюстрации показаны этапы процесса в спецификации на примере.
Антипаттерны
Антишаблоны - это определенные шаблоны в разработке программного обеспечения, которые считаются плохой практикой программирования. В отличие от шаблонов проектирования, которые представляют собой общие подходы к общим проблемам, которые были формализованы и обычно считаются хорошей практикой разработки, анти-шаблоны являются противоположностью и нежелательны.
Антипаттерны порождают различные проблемы.
| Анти-шаблон | Проблемы |
|---|---|
| Нет сотрудничества |
|
| Не знаю, когда код закончен |
|
| Слишком подробные или слишком ориентированные на UI примеры |
|
| Требуется недооценка усилий |
|
Решение проблем - качество
Качество можно гарантировать, следя за анти-образцами. Чтобы свести к минимуму проблемы, создаваемые антишаблонами, вам следует:
Соберитесь вместе, чтобы уточнить на примерах.
Очистите и улучшите примеры.
Напишите код, который удовлетворяет примерам
Автоматизируйте примеры и разверните.
Повторите этот подход для каждой пользовательской истории.
Решать проблемы из-за антипаттернов означает соблюдение -
Collaboration.
Сосредоточение внимания на чем.
Ориентация на бизнес.
Будь готов.
Давайте разберемся, что означает каждое из вышеперечисленных.
Сотрудничество
В сотрудничестве -
Деловые люди, разработчики и тестировщики вносят свой вклад со своей точки зрения.
Автоматизированные примеры доказывают, что команда построила правильную вещь.
Процесс более ценен, чем сами тесты.
Сосредоточившись на чем
Вы должны сосредоточиться на вопросе - «что». Сосредоточившись на том, «что» -
Не пытайтесь охватить все возможные случаи.
Не забывайте использовать разные тесты.
Делайте примеры как можно проще.
Примеры должны быть легко понятны пользователям системы.
Инструменты не должны играть важную роль в мастерских.
Ориентация на бизнес
Чтобы сосредоточиться на бизнесе -
Соблюдайте спецификацию в соответствии с бизнес-намерениями.
Включите бизнес в создание и рассмотрение спецификаций.
Скройте все детали на слое автоматизации.
Будь готов
Будьте готовы к следующему -
Выгоды не очевидны сразу, даже если методы работы в команде изменились.
Внедрить SbE сложно.
Требует времени и вложений.
Автоматическое тестирование не предоставляется бесплатно.
инструменты
Использование инструментов не обязательно для спецификации на примере, хотя на практике доступно несколько инструментов. Есть случаи, когда после «Спецификации на примере» удается успешно справиться даже без использования инструмента.
Следующие инструменты поддерживают спецификацию на примере -
Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog