Многие знакомы с методологией Test-Driven Development и, в частности, Behavior-Driven Development. Этот подход к разработке и обеспечению качества ПО набрал большую популярность, поскольку позволяет выстроить четко установленное соответствие между бизнес-требованиями и технической реализацией продукта.
На Russian Python Week 2020 Владислав Мухаматнуров, Senior QA automation на примере проекта голосового ассистента в Tinkoff, разобрал задачи, которые решает BDD. В своем докладе Влад разобрал, что такое BDD и Gherkin, откуда возникает потребность в поведенческом тестировании на проекте и как выглядит имплементация предметно-ориентированного языка для тестирования, базирующейся на диалогах системы. А под катом мы предлагаем вам прочитать расшифровку доклада.
Проект: Голосовой Ассистент «Олег»
Это тот самый голосовой помощник, который помогает людям в чатах мобильных приложений или когда они звонят в банк. Голосовой ассистент Олег от Tinkoff Mobile берет трубку и общается с клиентами.
Давайте подробнее поговорим об этом проекте:
Микросервисная архитектура.
В основе системы лежит:
Классификация и распознавание намерения пользователя;
Генерация действий на входное воздействие;
Сообщения в диалогах классифицируются на основе направленного ациклического графа.
Направленный ациклический граф
Это граф, который имеет начальный и конечный узлы, и из первого во второй можно добраться различными путями, в том числе параллельными. Но при этом нельзя выйти из начального узла и вернуться обратно в начальный узел.
Основные сервисы:
диалоговая платформа, которая осуществляет маршрутизацию сообщений клиента по нужным каналам обработки;
классификаторы, позволяющие выделять полезную нагрузку из сообщений пользователя и правильно понимать, как ее нужно обработать;
CRM-система, которая содержит процедуры работы с клиентами;
вспомогательные сервисы.
Тестирование на проекте
Однажды мы задались вопросом, как организовать тестирование на таком сложном проекте? Более того, у нас появились другие вопросы:
что у нас является тест-кейсом?
каким может быть входное воздействие на нашу систему?
каким может быть результат обработки сообщений?
как все это автоматизировать?
Мы начали думать и формулировать, как могут быть выражены бизнес-кейсы использования нашей системы. Для начала нужно было посмотреть на диалоги системы и пользователя:
Есть четко регламентированные воздействия на систему со стороны пользователя, а в ответ на эти воздействия система что-то генерирует. Попытаемся классифицировать эти ответы.
Посмотрим на взаимодействие в чате.
Действия пользователя:
напечатать текст;
надиктовать текст голосом;
нажать на подсказку;
нажать на кнопку виджета;
отправить файл.
Действия бота:
ответить текстом;
ответить текстом и голосом;
отправить подсказку;
отправить виджет;
отправить файл.
То есть бот делает то же самое, что пользователь, но в обратную сторону.
Описание бизнес-кейса
На основе этого сформировалось понимание, как может выглядеть бизнес-кейс на бумаге. Например:
User stories
В примере приведена пользовательская история. Это способ описания требований к разрабатываемой системе, сформулированных при помощи предметно-ориентированного языка.
Особенности user stories:
быстрый способ документировать требования бизнеса к реализации продукта;
минимизация обширных формализованных технических и бизнес спецификаций;
низкая цена поддержки.
На основе этого мы сформулировали требования к нашему процессу обеспечения качества и, в принципе, к улучшению процесса разработки на проекте.
Так, мы хотели связать постановку технических и бизнес-задач на основе историй использования системы, получить фундамент для тест-кейсов на основе бизнес-кейсов, автоматизировать регресс системы на основе пользовательских историй. Кроме того, нам было важно пополнить процесс разработки возможностью описать поведение системы и при помощи этих историй добиваться ее работоспособности согласно сценариям.
Я расскажу о чертах BDD или «разработки на основе поведения».
Behaviour-Driven Development
BDD — это ответвление методологии разработки через тестирование. Суть BDD заключается в том, что у нас есть бизнес-требования к продукту, которые мы описываем на предметно-ориентированном языке и получаем сценарий использования системы. Далее реализуем техническую часть системы и в конечном итоге создаем крутой конкурентноспособный продукт.
Классический цикл Behaviour-Driven Development состоит из 5 шагов:
Описываем поведение системы.
Определяем технические требования к системе.
Запускаем тесты или руками проверяем сценарии поведения. А они, естественно, падают, потому что система еще не готова или не реализована.
Дорабатываем нашу систему, то есть создаем, обновляем, дополняем, изменяем.
Добиваемся того, чтобы система проходила наши сценарии использования.
В основе BDD лежат спецификации поведения. Это документы, которые имеют следующую структуру:
заголовок — описание бизнес-цели;
описание — субъект, состав истории, ценность для бизнеса;
сценарии — ситуация поведения субъекта.
Gherkin и детали имплементации BDD
Gherkin — это предметно-ориентированный язык (по сути DSL), который позволяет описать поведение системы при помощи специальных ключевых слов, заранее зафиксированных.
Пример сценария, написанного на Gherkin:
В Gherkin употребляются ключевые слова. Их можно объединить по 4 основным группам:
Шаблон:
Background / Предыстория
Scenario / Сценарий
Scenario Outline / Структура сценария
Таблицы:
Examples / Примеры
Язык Gherkin: ключевые слова
Шаги:
Given / Дано
When / Когда
Then / Тогда
Предлоги:
And / И
But / Но
Пройдемся по этим ключевым словам.Ключевое слово: Функция.
Это название спецификации, отражающее определенную бизнес-функцию. Первая строчка в документе, описывающем ее, должна начинаться с ключевого слова «Функция:».
Ключевое слово: Сценарий.
Рядом с ключевым словом размещается краткое описание сценария.
Ключевое слово: Структура сценария.
Структура сценария позволяет избежать повторения конструкций. Когда вы пишете много похожих друг на друга сценариев, их можно шаблонизировать. Для этого и употребляется структура сценария.
Ключевое слово: Примеры.
Это таблицы с данными для параметризации структуры сценария. Они могут содержать много переменных, быть заданы горизонтально и вертикально, как представлено в примере.
Ключевое слово: Предыстория.
Предыстории добавляют определенный контекст ко всем Сценариям в пределах Функции. Фактически, Предыстория — это сценарий без имени, состоящий из конечного множества шагов, которые, как правило, специфицируют систему и пользователя перед каждым Сценарием.
Ключевое слово: Дано.
Назначение шагов Дано состоит в приведении системы и ее пользователя в определенное состояние. Их можно рассматривать как предусловия сценария.
Ключевое слово: Когда.
Основная задача этого ключевого слова состоит в описании ключевого воздействия, совершаемого пользователем на нашу систему.
Ключевое слово: Тогда.
Оно необходимо для наблюдения за результатом выполнения действий. По сути, для проверки вывода системы (отчеты, интерфейс, сообщения). Наблюдения должны быть связаны с описанием Функции и Сценария.
Ключевые слова: И, Но.
Это предлоги. Они необходимы, когда есть несколько последовательных шагов Дано, Когда или Тогда. В данном случае предлог И — это смысловой аналог конъюнкции, а предлог Но — смысловой аналог инверсии.
Пример диалога системы с пользователем
Рассмотрим простейший пример, где пользователь пишет «Привет!», а бот отвечает ему текстом и показывает подсказки:
Рассмотрим, как это можно зафиксировать при помощи наших сценариев и спецификаций поведения.
Пример использования Gherkin
Здесь есть конкретная Функция: Бот умеет приветствовать пользователя. Кроме того, мы видим предысторию, о том, что это за клиент, в какой ОС он сидит и какую версию приложения использует. Ведь в зависимости от разных версий приложения могут быть показаны разные виджеты.И у нас есть сам сценарий, согласно которому в ответ на то, что пользователь пишет: «Привет!», бот отвечает фиксированным текстом и дает фиксированные подсказки.
Пример отчета по сценарию поведения
Это автоматически сгенерированный отчет при помощи нашего внутреннего инструмента автоматизации, который отражает сценарий поведения с результатом Passed:
Пример посложнее: «Поездка за границу»
Тут пользователю необходимо написать о своем намерении уехать за границу. Бот это поймет, предложит добавить поездку, и начнется выбор страны, даты отъезда и т.д. А дальше мы ждем, что пользователь подтвердит факт, что поездка планируется.
Так может выглядеть этот бизнес-кейс при помощи нашего предметно-ориентированного языка:
То, что вы видите в приложении и пишите системе, описывается в сценариях поведения. У нас появляется прямое соответствие бизнес-кейсов и тест-кейсов, то есть они, по сути, идентичны.
А при помощи инструмента автоматизации можно собирать входные воздействия и добавлять регресс, автоматизировать, делать аналитику на основе получаемых данных.
Пример отчета по сценарию поведения
Интересно рассмотреть, как реализуется Gherkin «под капотом».
У нас есть инструмент автоматизации. К нему прикручивается плагин имплементации конкретно для нашего языка программирования. Далее, на основе этой конструкции, реализуется каркас предметно-ориентированного языка, и затем можно писать спецификации поведения.
Задачи, решаемые BDD
Я выделил три важные задачи, которые решает разработка на основе поведения:
объединение бизнеса и разработки;
установление единого восприятия бизнес-кейсов;
удешевление поддержки тест-кейсов.
Рассмотрим классическую ситуацию.
У нас есть продукт, а у него продакт-менеджер. Он хочет очередной бизнес-эпик, описывает его в виде бизнес-требований и передает в команду.
У команды есть технический аналитик, который на основе бизнес-требований формирует технический эпик и техническую спецификацию по данной фиче. На основе технической спецификации команда разработки реализует функциональность. Согласно задачам, эта функциональность поступает в отдел тестирования. И QA при помощи тест-кейсов тестирует фичу, находит баги или подтверждает работоспособность нашей системы.
В конечном итоге у нас сформирована спецификация по тестированию данной фичи.
Итак, у нас есть три основные документа:
Бизнес-требования к продукту.
Техническая спецификация продукта.
Спецификация по тестированию продукта.
И вот он — классический случай, где каждый из документов является новым отображением на основе предыдущего документа. Проблема в том, что у нас нет единого понимания, что такое сценарий использования приложения, и часто размыты понятия поведения системы и пользователя в этих документах. Как следствие, бизнес-кейсы сильно отличаются от тест-кейсов. Разница в формате реализации документов приводит к проблемам в восприятии информации участниками процесса.
Например, продакт-менеджер приходит и задает важный и правильный вопрос про фичу у продукта.
Чтобы ответить на него, QA переводит с бизнес-языка на технический: что за пользователь, как реализуются обработка конкретной группы и выполнение условия C в системе?
А потом смотрит, есть ли у нас кейсы на проверку комбинации из заданных технических особенностей при указанном условии. Если кейсы есть, QA сразу дает ответ. А если нет, проверяет руками.
На картинке QA дает ответ на вопрос менеджера продукта, но как будто бы на своем языке. И он тоже прав. Он дал абсолютно корректный, правильный ответ. Но кажется, что этот ответ не совсем коррелирует с заданным вопросом.
BDD — это про объединение бизнеса и разработки. Постановка задач BDD от бизнеса выполняется в виде спецификаций поведения. Такие спецификации уже используются в качестве основы для технических требований, а также являются фундаментом для тест-кейсов.
Единое восприятие продукта
Мы начинаем воспринимать продукт одинаково. Когда менеджер в следующий раз задаст свой правильный и важный вопрос, QA ответит на его языке:
Он ответит так, потому что у него есть тот самый бизнес-кейс, который уже написан на Gherkin. В нем описывается функция и конкретный сценарий поведения.
У нас появляется единое восприятие бизнес-кейсов. Спецификации поведения (на основе утвержденного шаблона) понятны всем: продуктологам, аналитикам, разработчикам и тестировщикам.
Такие сценарии легко реализуемы. А если их автоматизировать, вы получите эффективный инструмент для сбора аналитики и формирования отчетов. Кроме того, эти сценарии позволят вам итеративно улучшать продукт.
Всё это можно делать непрерывно, ежедневно улучшая продукт. Также BDD позволяет удешевить поддержку тест-кейсов.
Спецификации поведения сами по себе реализуются на основе набора простых конструкций имплементированного предметно-ориентированного языка. По сути такие сценарии почти не зависят от программной реализации вашего инструмента автоматизации «под капотом».
То есть можно взять любой инструмент автоматизации, но при этом использовать один предметно-ориентированный язык, те же самые спецификации поведения, и все должно быть идентично. Не нужно переписывать тест-кейсы, если вы меняете фундамент инструмента автоматизации.
Давайте сравним тест-кейсы автоматизации: слева — уже привычный тест на Gherkin, справа — кейс на фреймворке Tavern.
Справа более технический тест-кейс, а слева, по сути, просто описание бизнес-функции. Но, как правило, всем приятнее видеть именно то, как работает система в тест-кейсах, и какие она генерирует ответы на запросы.
Преимущества интеграции BDD
На собственном опыте мы ощутили преимущества интеграции BDD:
Идеально тестировать диалоги чат-бота и говорящего робота.
Понятная спецификация системы и пользователя, например:
Версии приложения, ОС, часовой пояc.
Тип клиента, продукта, номер телефона.
На основе ограниченного набора шагов мы сделали маппинг. Используем ключевые слова:
Дано — для спецификации пользователя и системы, как это канонически предусмотрено.
Когда — для описания действий пользователя.
Тогда — для описания реакции системы.
Проблемы, не решаемые BDD
Процесс разработки: если он плохо поставлен, интеграция BDD не сделает его быстрее и качественнее.
Регрессионное тестирование: при отсутствии (или серьезной нестабильности) QA-контура или стейджинга не будет возможности обеспечить регресс на основе созданных сценариев поведения, в том числе, автоматизированный.
Релизный процесс: при отсутствии поставленных в командах проекта процессов по контролю качества и релизам, интеграция BDD не позволит гарантировать работоспособность согласно спецификациям поведения.
Если вы делаете BDD, нужно контролировать работоспособность системы до того, как все это выкатится в продакшен. Только тогда BDD принесет классные результаты.
Видео доклада можно увидеть тут.
Профессиональная конференция для Python-разработчиков пройдет 27 и 28 сентября в Москве. Но посмотреть расписание и выбрать самые интересные доклады можно уже сегодня.
Не забудьте купить билеты. Встречаемся в офлайне в конце сентября!
