Чат поддержки

Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи

пт, 2 декабряв 17:21

Мы уже начали заниматься вашим вопросом, ответим в ближайшее время

Практикум

Здравствуйте!

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

Если же у вас возникнут иные вопросы — обязательно пишите, будем рады помочь :)

17:24

Выбрать способ связи

Перейти в профиль Практикума

Поменять когорту

Выйти из профиля

Добавить аккаунт

Дополнительные материалы

спринт Дополнительные материалы

Как учиться на курсе

4/4

К проекту 2

0/1

К спринту "Реализация системы"

2/2

Техника BDD

CI/CD

К спринту "Поддержка, обслуживание и оценка результатов"

1/1

SQL и системы визуализации

11/11

SQL и Python

7/10

Мягкие навыки аналитика. Коммуникация и активное слушание

4/4

Мягкие навыки аналитика. Постановка задач

5/5

Мягкие навыки аналитика. Планирование

4/4

Пригласить друзей

Техника BDD

Вы уже знакомы с техникой разработки ПО через тестирование (test-driven development, TDD). Это техника программирования, при которой сначала пишутся тесты, а затем код. У TDD есть разновидность, которая отлично подходит для приёмочного тестирования, — BDD. О ней и расскажем в этом уроке.

Даня

А что, если мы не успеем протестировать ПО?

Айгуль

Всё успеваем, не переживай 😉 Но конструкция хорошая!

Даня

Ты о чём? Какая конструкция?

Айгуль

«А что, если…» Ты мне напомнил, что нужно тебе о технике BDD ещё рассказать.

Что такое BDD?

Что такое BDD

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

BDD (англ. behaviour-driven development — «разработка через поведение») — методология разработки ПО, основанная на пользовательских сценариях, ответвление техники TDD.

В BDD поведение пользователя описывается с помощью сценариев, понятных всем заинтересованным лицам.

Сценарии — это реальные бизнес-примеры поведения пользователей, предоставленные заинтересованными сторонами.

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

Тесное сотрудничество друг с другом и с заинтересованными лицами побуждает команду разработки думать как пользователь и разрабатывать только ту функциональность, которую он ожидает от ПО.

Особенности техники BDD:

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

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

Потребности клиентов описываются на естественном языке в формате, понятном всем членам команды. Язык основан на конкретных примерах, а не на абстрактных понятиях.

Язык BDD

Чтобы описывать предполагаемое поведение пользователя, в BDD используется человекочитаемый предметно-ориентированный язык. Чаще всего это язык Gherkin, с которым вы познакомились в спринте «Agile-практики».

Синтаксис Gherkin позволяет описывать реальные сценарии приёмки и тестирования. В нём сценарии описываются с помощью ключевых слов и символов и строятся по шаблону.

Какой из представленных шаблонов является шаблоном сценария на Gherkin?

Как <пользователь>, я хочу <мотивация>, чтобы <ожидаемый результат>

Это шаблон для описания пользовательских историй в формате User Story.

Неправильный ответ

Дано <ситуация>, Если <событие>, Тогда <ожидаемый результат>

В синтаксисе Gherkin нет ключевого слова «Если».

Тоже правильный ответ

Дано <ситуация>, Когда <событие>, Тогда <ожидаемый результат>

Шаги сценария на Gherkin описываются с помощью ключевых слов «Дано», «Когда», «Тогда». Кроме них, могут использоваться «И» или «Но» для составных условий.

Когда <ситуация>, я хочу <мотивация>, чтобы <ожидаемый результат>

Это шаблон для описания пользовательских историй в формате Job Story.

Использование Gherkin даёт возможность:

Описать поведение системы в простой форме, понятной всем участникам проекта.

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

Поучаствовать в автоматизации приёмочных испытаний самим пользователям — они тоже могут описывать сценарии.

Процесс BDD

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

Написать карточку истории.

Сформулировать критерии и сценарии приёмки.

Разработать функциональность.

Написать автотесты.

Провести тестирование.

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

Рассмотрим процесс на примере создания функциональности для банкомата.

Написание карточки истории

Системный аналитик составляет пользовательские истории, то есть примеры поведения пользователей, и тем самым разъясняет их ожидания от ПО.

Как клиент,
Я хочу, чтобы банкомат запрашивал ПИН-код перед совершением операций,
Чтобы мои деньги были надёжно защищены.

Формулирование критериев и сценариев приёмки

Затем системный аналитик, руководствуясь принципом «трёх друзей», приглашает разработчика и тестировщика для уточнения историй. Цель такой встречи — выявить дополнительные сценарии и выразить их в виде примеров. В процессе этого брейншторма тестировщик и разработчик задают как можно больше вопросов «А что, если?».

Например, для истории с банкоматом тестировщик может задать вопрос: «А что, если пользователь введёт неверный ПИН-код?»

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

Ключевой элемент BDD — описание сценариев в формате «Дано-Когда-Тогда» (Given-When-Then). Поэтому в процессе обсуждения аналитик записывает сценарии, используя язык Gherkin. Такие сценарии дают точное понимание функциональности, которую должен разработать программист. Тестировщик, в свою очередь, сможет использовать эти описания, чтобы подготовить тесты, которые проверят соответствие ПО этим сценариям.

В результате обсуждения и уточнения истории для банкомата СА записал следующие сценарии:

Функция: проверка ПИН-кода карты

Как клиент,
Я хочу, чтобы банкомат запрашивал ПИН-код для совершения операций,
чтобы мои деньги были надёжно защищены

Банкомат открывает экран операций с картой, если ПИН-код введён верно
Банкомат выдаёт предупреждение, если введён неверный ПИН-код

Сценарий: банкомат отображает экран операций с картой, если ПИН-код введён верно
Дано клиент вставляет банковскую карту в банкомат
И банкомат запрашивает ПИН-код
Когда клиент вводит верный ПИН-код
Тогда банкомат отображает экран доступных операций

Сценарий: банкомат выдаёт предупреждение, если введён неправильный ПИН-код
Дано клиент вставляет банковскую карту в банкомат
И банкомат запрашивает ПИН-код
Когда клиент вводит неверный ПИН-код
Тогда банкомат отображает предупреждение

Даня

Так, а когда сценарии написаны, что дальше происходит?

Айгуль

Разработчики приступают к их реализации!

Тестировщики их автоматизируют!

Даня

Каким образом?

Айгуль

Используют фреймворки 😉

Как это работает?

Разработка функциональности

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

Написание автотестов

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

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

Фреймворки BDD

Фреймворк (англ. framework — «каркас, структура») — это готовая модель для быстрой разработки, на основе которой можно дописать собственный код. Он задаёт структуру, определяет правила написания кода и предоставляет разные инструменты для быстрого создания проекта на определённом языке программирования.

Есть фреймворки, которые работают со сценариями, написанными в формате BDD, но могут иметь свой собственный синтаксис и структуру. Такие фреймворки позволяют легко преобразовывать сценарии в автоматизированные тесты.

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

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

Cucumber — один из самых популярных фреймворков BDD, который используется для автоматизации тестирования на различных языках программирования, включая Java, Ruby, Python и другие.

Behave — фреймворк BDD для Python. Behave имеет обширную документацию и поддерживается сообществом.

JBehave — фреймворк BDD для Java. Он позволяет описывать сценарии с помощью собственного синтаксиса JBehave, а также с помощью синтаксиса Gherkin. Также в нём реализована интеграция с Apache Maven.

SpecFlow — бесплатный фреймворк для языков программирования Microsoft. NET (C++, C# и других). Он позволяет описывать функциональность системы на бизнес-уровне и автоматически генерировать тестовые случаи. SpecFlow также предоставляет интеграцию с Visual Studio и поддержку для нескольких языков.

Jasmine — фреймворк BDD для JavaScript, который применяется для тестирования клиентских приложений, кросс‑браузерного тестирования и тестирования Node.js. Он использует сценарии в формате BDD для описания спецификаций и предоставляет множество встроенных функций для тестирования.

Выберите из выпадающего списка язык программирования для каждого фреймворка.

Jasmine

JavaScript

Jasmine используется для тестирования клиентских приложений на JavaScript.

SpecFlow

C#

Фреймворк SpecFlow подходит для всех языков программирования Microsoft. NET, включая C#.

JBehave

Scala

JBehave подходит для JVM‑подобных языков, в число которых входит Scala.

Cucumber

Ruby

Этот популярный фреймворк подходит для многих языков, включая Ruby.

Начать заново

Тестирование

Когда функциональность полностью готова, а автотесты для неё написаны, тестировщик проверяет готовую функциональность с помощью автотестов.

В рамках этого этапа происходит отладка и исправление ошибок. Этот процесс может потребовать совместных усилий тестировщика и аналитика. Если тест не проходит, тестировщик должен сообщить об этом СА, чтобы тот мог проанализировать проблему и предложить решение.

Также на этом этапе может потребоваться обновление тестов. Если функциональность продукта изменится или добавится новая, то аналитик должен обновить тестовые сценарии, а тестировщик — соответствующие тесты, чтобы проверить, что все функции продукта работают правильно.

Расставьте в правильной последовательности действия команды разработки в рамках BDD.

Системный аналитик выявляет у заказчика и пользователей ожидания от ПО.

1

Первым делом СА разъясняет ожидания заказчиков и пользователей от ПО. Для этого он составляет пользовательские истории, то есть примеры поведения пользователей.

Тестировщик запускает автотесты

4

Запуск автотестов происходит, когда функциональность полностью готова.

Тестировщик пишет автотесты для проверки сценариев

3

Когда сценарии написаны, тестировщик приступает к написанию автотестов. Одновременно с этим разработчик приступает к написанию кода.

«Три друга» уточняют истории и записывают сценарии на языке Gherkin.

2

Когда СА написал истории, он приглашает тестировщика и разработчика для уточнения требований.

Начать заново

Выберите задачи, которые выполняет системный аналитик в рамках BDD.

Правильный ответ

Записывает требования к ПО в формате пользовательских историй

Это ключевая задача СА в рамках BDD — предоставить тестировщику и разработчику требования на понятном им языке.

Пишет сценарии автотестов

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

Правильный ответ

Участвует в уточнении требований

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

Правильный ответ

Принимает решения по результатам запуска автотестов

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

Преимущества и недостатки BDD

Преимущества техники BDD:

Структура BDD способствует автоматизации приёмочных испытаний и поддерживает создание эффективных тест-кейсов.

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

BDD обеспечивает гибкость документации, создавая лёгкий, живой документ с требованиями и тестированием. Это значит, что СА нет необходимости дополнительно описывать поведение системы — всё это будет описано в проекте в нескольких файлах.

Недостатки:

Можно упустить важные сценарии, если только кто-то не будет активно задавать вопросы «а что, если» и «а как насчёт».

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

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

Подведём итоги

BDD (англ. behaviour-driven development — «разработка через поведение») — методология разработки ПО, основанная на пользовательских сценариях, ответвление техники TDD.

Сценарии — это реальные бизнес-примеры поведения пользователей, предоставленные заинтересованными сторонами. Сценарии записываются в формате пользовательских историй.

Для описания сценариев в BDD используется человекочитаемый предметно-ориентированный язык Gherkin. Он позволяет описать поведение системы в простой форме, понятной всем участникам проекта, а также автоматизировать тестовые сценарии.

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

Написать карточку истории.

Сформулировать критерии и сценарии приёмки.

Разработать функциональность.

Написать автотесты.

Провести тестирование.

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

К следующему уроку
Краткий пересказ урока
beta

Курсы

Вводный модуль

Понимание профессии системного аналитика

Разработка требований

Проект 1. Спецификация требований ко второму релизу Chatty

SQL для аналитиков

Моделирование данных

Проект 2. Моделирование данных и работа с базой данных интернет-магазина «Накарабине»

Моделирование процессов

Пользовательские интерфейсы

Agile-практики

Проект 3. Бэклог приложения для сети клиник «Вита»

Трудоустройство

Архитектура системы

Программные интерфейсы

Проект 4

Реализация системы

Поддержка, обслуживание и оценка результатов

Дипломный проект

Дополнительные материалы

x