На каких языках «говорят» автоматизаторы?
Для создания фреймворка по автоматизации и базирующихся на нем автотестов разработчики используют различные языки: C#, JavaScript, Ruby и т.д.
У каждого их этих языков свой уникальный синтаксис. Выбор того или иного языка может быть обусловлен пожеланием клиента,
экспертизой команды автоматизаторов или наличием специфических библиотек для конкретного технологического стека. И если навыки программирования на конкретном языке присущи инженерам по автоматизации, пишущим решение, то совсем необязательно, что этими же навыками обладают люди, которые будут использовать решение в дальнейшем.
В использование
решения по автоматизации входят запуск, анализ автотестов, а также их поддержка, т.е. актуализация в свете изменения UI или бизнес-логики приложения. Кроме того, что решение по автоматизации должно приносить пользу клиенту, оно также должно быть понятным и удобным.
Кто использует решение по автоматизации?
После того, как решение по автоматизации написано и передано клиенту, использовать его могут следующие команды:
- Сами автоматизаторы (проблемы в понимании языка не существует, т.к. решение будет использоваться инженерами его написавшими);
- Разработчики заказчика (обычно в этом случае решение создается в том технологическом стеке, который использует отдел разработки – как следствие, проблемы с пониманием языка программирования нет);
- QA-команда заказчика — самый распространенный вариант. И здесь возникает проблема, о решении которой мы и будем говорить далее.
Очень четко эту проблему сформулировал один из наших потенциальных клиентов после того, как мы продемонстрировали ему наш фреймворк и подходы к автоматизации. Он высказал вполне закономерные опасения, что его внутренняя QA-команда, не имеющая опыта в написании кода, просто не сможет поддерживать написанные автоматизаторами тесты, не говоря уже о самостоятельном создании новых тестов по мере развития продукта. Решением в данной ситуации станет BDD (Behavior-Driven Development) подход.
Заказать консультацию по автоматизации тестирования ПО
можно здесь.
Чем интересен bdd-подход?
Когда конечными пользователями решения выступают тестировщики, не обладающие навыками программирования, мы предлагаем создание решения на основе BDD к
автоматизации тестирования.
Подобный подход пришел к нам из разработки. Суть его состоит в том, что изначально на основе определенных лингвистических шаблонов составляются верхнеуровневые сценарии, описывающие вероятное поведение системы. После этого разрабатывается функциональность.
Ожидается, что после завершения разработки предопределенные тестовые сценарии станут успешно выполняться.
BDD-подход интересен тем, что тесты к нему пишутся с помощью сценариев.
Сценарий – описание поведения определенной функциональности системы, составленное на естественном языке по определенному шаблону. Важно, что для подготовки сценариев используются общеупотребительные языки (ubiquitous language). Это позволяет автоматизаторам и тестировщикам заказчика легко составлять сценарии вместе.
Общеупотребительный язык – определенные лингвистические конструкции, интерпретируемые программным кодом автотестов. Как следствие, отпадает необходимость трудозатрат на преломление, изменение или же конкретизацию документации под разработку или QA. Сценарии изначально едины и неизменны для всех вовлеченных в проект команд.
Описываем тестовые сценарии на языке gherkin
Язык, на котором составляются подобные тестовые сценарии, – Gherkin. Он выполняет сразу две задачи:
- представляет собой проектную документацию;
- автоматизирует процесс тестирования.
Поведение системы описывается на естественном языке, но в так называем «Given/When/Then» формате. Каждая непустая строка в Gherkin начинается с ключевых слов, за которыми следует описание.
В соответствии с BDD-подходом, спецификации должны иметь следующую структуру
Название
Спецификация должна иметь четкое, явное название, отражающее суть тестируемой функциональности.
Повествование
Краткий вводный раздел, который определяет:
- кто действующее лицо или стейкхолдер юзер-стори;
- необходимые действия, поведение или функцию;
- выгоду или ценность для бизнеса, которую получает пользователь, когда история реализуется.
Язык Gherkin пример
Обычно юзер-стори записывается в следующем формате:
Как (As a) [X]
Я хочу (I want) [Y]
Чтобы (so that) [Z]
где Y – это некая функциональность («фича»), Z – это выгода, которую мы от нее получаем, или ценность, а X – это человек или группа людей, которая получит ценность от данной функциональности.
Эти три строчки в примере не интерпретируются программным кодом и являются общепринятым шаблоном, следовать которому, однако, необязательно при написании спецификаций.
Другое дело – блок сценариев в Gherkin, где каждая строка представляет собой шаг, причем каждый шаг соответствует одному из методов программного кода.
Сценарий начинается с задания начального состояния — предусловия. Оно может состоять из одного пункта или сразу нескольких и в Gherkin следует за ключевым словом [Given].
После начального состояния описываются действия, совершающиеся в ходе сценария — в Gherkin они следуют за ключевым словом [When].
И наконец, описывается ожидаемый результат в одном или нескольких пунктах [Then].
Если шагов в блоках Given, When или Then несколько, то каждый из них записывается с новой строки и следует за ключевым словом And.
Пример структуры спецификации Gherkin
Функциональность: Вход в приложение
Как пользователь
Я хочу войти в свой аккаунт
Чтобы совершить платеж онлайн
В 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
-
Сценарии, определяющие поведение системы, описываются в простой форме и могут быть понятны всем участникам проекта.
-
Файлы, содержащие в себе спецификации, одновременно являются и исполняемыми автотестами.
-
Тестовая документация и программный код автотестов хранятся в одном проекте и неотделимы друг от друга.
-
Наличие словаря доступных шагов допускает вариативность сценариев и позволяет тестировщикам составлять новые автотесты, не обращаясь к программному коду.
