Блог A1QA

О тестировании и качестве ПО

Gherkin: говорим с автоматизаторами на одном языке

Вместе разбираемся в преимуществах языка Gherkin, который позволяет тестировщикам «подхватывать» решение по автоматизации и создавать автотесты самостоятельно.

В данной статье Сергей Сенюк, менеджер команды автоматизаторов A1QA, знакомит нас с языком Gherkin, позволяющим описывать сценарии для тестирования и создавать автотесты, не заглядывая в программный код.

На каких языках «говорят» автоматизаторы?

Для создания фреймворка по автоматизации и базирующихся на нем автотестов разработчики используют различные языки: C#, JavaScript, Ruby и т.д.

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

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

Кто использует решение по автоматизации?

После того, как решение по автоматизации написано и передано клиенту, использовать его могут следующие команды:

  • Сами автоматизаторы (проблемы в понимании языка не существует, т.к. решение будет использоваться инженерами его написавшими);
  • Разработчики заказчика (обычно в этом случае решение создается в том технологическом стеке, который использует отдел разработки – как следствие, проблемы с пониманием языка программирования нет);
  • Но самый распространенный вариант — QA-команда заказчика. И здесь возникает проблема, о решении которой мы и будем говорить.

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

В подобных случаях, когда конечными пользователями решения выступают тестировщики, не обладающие навыками программирования, мы предлагаем создание решения на основе BDD (Behavior-Driven Development) подхода к автоматизации тестирования.

Чем интересен BDD-подход?

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

BDD-подход интересен тем, что тесты к нему пишутся с помощью сценариев.

Сценарий – описание поведения определенной функциональности системы, составленное на естественном языке по определенному шаблону. Важно, что для подготовки сценариев используются общеупотребительные языки (ubiquitous language). Это позволяет автоматизаторам и тестировщикам заказчика легко составлять сценарии вместе.

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

Описываем тестовые сценарии на языке Gherkin

Язык, на котором составляются подобные тестовые сценарии,  –  Gherkin. Он выполняет сразу две задачи:

  • представляет собой проектную документацию;
  • автоматизирует процесс тестирования.

Поведение системы описывается на естественном языке, но в так называем «Given/When/Then» формате. Каждая непустая строка в Gherkin начинается с ключевых слов, за которыми следует описание.

В соответствии с BDD-подходом, спецификации должны иметь следующую структуру:

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

Повествование. Краткий вводный раздел, который определяет:

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

Обычно юзер-стори записывается в следующем формате:

Как (As a) [X]
Я хочу (I want) [Y]
Чтобы (so that) [Z]

где Y – это некая функциональность («фича»), Z – это выгода, которую мы от нее получаем, или  ценность, а X – это человек или группа людей, которая получит ценность от данной функциональности.

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

Другое дело – блок сценариев в Gherkin, где каждая строка представляет собой шаг, причем каждый шаг соответствует одному из методов программного кода.

Сценарий начинается с задания начального состояния — предусловия. Оно может состоять из одного пункта, или сразу нескольких и в Gherkin следует за ключевым словом [Given].

После чего описываются действия, совершающиеся в ходе сценария — в Gherkin следует за ключевым словом [When].

И, наконец, описывается ожидаемый результат, в одном или нескольких пунктах [Then].

Если шагов в блоках Given, When или Then несколько, то каждый из них записывается с новой строки и следует за ключевым словом And.

Пример структуры спецификации

Функциональность: Вход в приложение

Как пользователь

Я хочу войти в свой аккаунт

Чтобы совершить платеж онлайн

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

Given User is on Login Page

When User enters following credentials and submit

|Name         |Value         |

|Login          |test_user  |

|Password   |pass           |

Then ‘Welcome to our site’ message should be displayed

Разработчики BDD-фреймворков поддерживают мультиязычность. Фреймворк Cucumber, например, поддерживает более 60 языков, и это число постоянно растет. Так спецификация на русском языке будет выглядеть следующим образом:

Допустим пользователь находится на странице логина

Когда пользователь вводит следующие данные

|Имя           |значение   |

|Логин        |значение   |

|Пароль     |значение   |

Тогда должно появиться приветственное сообщение

Использование языка Gherkin удобно по ряду причин:

  1. Сценарии, определяющие поведение системы, описываются в простой форме и могут быть понятны всем участникам проекта.
  2. Файлы, содержащие в себе спецификации, одновременно являются и исполняемыми автотестами.
  3. Тестовая документация и программный код автотестов хранятся в одном проекте и неотделимы друг от друга.
  4. Наличие словаря доступных шагов допускает вариантивность сценариев и позволяет тестировщикам составлять новые автотесты, не обращаясь к программному коду.

Так что, коллеги-тестировщики, учите Gherkin и говорите на одном языке с автоматизаторами!

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

Поделиться статьей: