Комментарии 23
Однажды видел (возможно, в виде упоминания на Хабре) интересный вариант применения Gherkin: допустим, первая версия продукта пишется на Ruby в целях ускорения разработки. Для неё пишутся тесты на Gherkin. Затем, когда продукт уже выпущен, набирает пользователей и в целом более-менее устоялся, его начинают переписывать, к примеру, на Java. Тогда надо просто переписать step_definitions с Ruby на Java, а сами сценарии (которых могут быть тысячи) остаются неизменными. Конечно, редкий случай, но для него применение Gherkin весьма полезно.
В моем понимании, Gherkin предназначен исключительно для описания поведения системы.
Скажу сразу — мое понимание может быть не до конца верным, потому что мне почему-то так и не попалось цельное руководство по этому языку, буду очень признателен, если посоветуете какой-нибудь авторитетный материал по этой теме.
Но если мое понимание верно, то полезность Gherkin для аналитика есть, но она не очень велика, т.к. описание поведения системы — это лишь малая часть того, с чем сталкивается аналитик.
Для бизнеса полезность еще меньше, т.к. бизнес не умеет и не должен, вообще говоря, уметь разговаривать на формальных языках.
Скажу сразу — мое понимание может быть не до конца верным, потому что мне почему-то так и не попалось цельное руководство по этому языку, буду очень признателен, если посоветуете какой-нибудь авторитетный материал по этой теме.
Но если мое понимание верно, то полезность Gherkin для аналитика есть, но она не очень велика, т.к. описание поведения системы — это лишь малая часть того, с чем сталкивается аналитик.
Для бизнеса полезность еще меньше, т.к. бизнес не умеет и не должен, вообще говоря, уметь разговаривать на формальных языках.
У нас бизнес-аналитики перестали плеваться примерно после того как мы стали писать в сценариях вместо
что-то вроде этого:
я нажимаю на ссылку «войти»
я ввожу «васяпупкин» в поле мыла
я ввожу «васяпупкин1111» в поле пароля
я нажимаю на кнопку «войти»
я должен увидеть «здравствуйте, Вася Пупкин!»
что-то вроде этого:
Я пользователь Вася Пупкин
А что означает последняя фраза «Я пользователь Вася Пупкин»?
И какой смысл в сценарии:
КОГДА
я пользователь Вася Пупкин
ТОГДА
я должен увидеть «Здравствуйте, Вася Пупкин!»
Проще тогда уже написать по-человечески: «После авторизации пользователь видит страницу приветствия, на которой отображается текст: „Здравствуйте, <Имярек>!“
— как и пишут аналитики в спецификациях.
И какой смысл в сценарии:
КОГДА
я пользователь Вася Пупкин
ТОГДА
я должен увидеть «Здравствуйте, Вася Пупкин!»
Проще тогда уже написать по-человечески: «После авторизации пользователь видит страницу приветствия, на которой отображается текст: „Здравствуйте, <Имярек>!“
— как и пишут аналитики в спецификациях.
Если цель фичи — проверить приветствие, то можно написать
Но приветствие это вообще не фича обычно. Я имел ввиду, что мы пишем всякие более высокоуровневые вещи типа
вместо
Given Я пользователь Вася Пупкин
When Я логинюсь
Then Я должен увидеть приветствие
Но приветствие это вообще не фича обычно. Я имел ввиду, что мы пишем всякие более высокоуровневые вещи типа
Я пользователь Вася Пупкин
У меня баланс $100
Я покупаю подписку
У меня баланс должен стать $50
вместо
Я нажимаю «логин»
…
Я нажимаю «оплатить»
…
Я должен увидеть $50
А это реально помогает? Просто сразу приходит на ум пример из реальной жизни:
Я абонент оператора «Лучшая мобильная связь» со стажем больше 3 лет
У меня есть набор услуг: сотовая связь, мобильный интернет
Мой тариф включает различные опции для телефонии и интернета
Мой кредит составляет 100 рублей
Если я позвоню своей теще, у которой «дружественный» тарифный план, сколько денег у меня останется на счете через 13 минут разговора, при условии, что мы находимся в разных регионах?
В данном примере, ограничимся параметрами расчета (тоже все из жизни):
1. Стаж больше 3 лет? (да, нет)
2. Программа поощрения абонентов со стажем в настоящий момент действует? (да, нет)
3. Опции понижающие тариф включены? (да, нет)
4. Дружественный тариф есть? (да, нет)
5. Между регионами есть роуминг? (да, нет)
Итого 32 возможных вариантов исхода при расчете. Не удобнее ли все эти кейсы формализовать одновременно в виде таблицы решений, а не в виде 32 различных WHEN-THEN сценариев?
Я абонент оператора «Лучшая мобильная связь» со стажем больше 3 лет
У меня есть набор услуг: сотовая связь, мобильный интернет
Мой тариф включает различные опции для телефонии и интернета
Мой кредит составляет 100 рублей
Если я позвоню своей теще, у которой «дружественный» тарифный план, сколько денег у меня останется на счете через 13 минут разговора, при условии, что мы находимся в разных регионах?
В данном примере, ограничимся параметрами расчета (тоже все из жизни):
1. Стаж больше 3 лет? (да, нет)
2. Программа поощрения абонентов со стажем в настоящий момент действует? (да, нет)
3. Опции понижающие тариф включены? (да, нет)
4. Дружественный тариф есть? (да, нет)
5. Между регионами есть роуминг? (да, нет)
Итого 32 возможных вариантов исхода при расчете. Не удобнее ли все эти кейсы формализовать одновременно в виде таблицы решений, а не в виде 32 различных WHEN-THEN сценариев?
Конкретно в этом случае я бы не писал 32 варианта, т.к. большинство из опций не влияют друг на друга. Я бы написал отдельно сценарии на конкретные опции и совместил бы где-то, где реально есть влияние. Но таблицы это тоже очень мощный и удобный инструмент задания примеров, в Gherkin они предусмотрены через Schenario Outline / Examples. Мы их активно юзаем тоже для подобных данных, где очень много примеров однотипных. Вопрос тут скорее в том, чтобы по максимуму убирать примеры, которые не интересны бизнесу. Если, например, стаж дает 10% скидку при условии включения программы поощрения, нету смысла делать 10 сценариев со стажем + программой и различными вариантами других опций, потому что знаний никаких в них не добавится, можно сделать просто несколько сценариев со стажем, программой и каким-то фиксированным набором других опций.
Джеркин разрешает составление таблицы этих 32-х вариантов - не проблема
Потом идем по таблице и проверяем каждый вариант
бтв: у вас очень грамотно поставлена задача, респект
Похоже, что в приведенном примере, бизнес-аналитики прокачали или им помогли прокачать скилл проектирования сценариев тестирования.
Можно и так сказать. Но BDD это скорее не про тестирование. Если у нас простой проект и там все понятно в требованиях, то просить BA писать эти сценарии бессмысленно — действительно, с этим лучше справятся QA. Но все меняется, когда требования сложные. Тут сценарии помогают их описывать и обсуждать намного проще, чем всякие спеки, описывающие требования. И как byproduct мы имеем пак приемочных тестов.
О чем постоянно твердят люди, продвигающие BDD. Сценарии это не тесты. Сценарии это способ обмена знаниями. Сценарий позволяет с бОльшей уверенностью сказать, что все участники понимают систему одинаково. Позволяют всем общаться на одном и том же языке. Автотесты это приятное дополнение.
А некоторые, вообще говорят, что тестов не существует, а есть проектирование поведения.
НЛО прилетело и опубликовало эту надпись здесь
Не знаю, почему ты решил, что Gherkin меня не впечатлил. Я вполне нормально к нему отношусь и очень даже вижу область его применения.
Цель статьи — показать, что для Gherkin'а неверно выбрана целевая аудитория и что стоит начать продвигать этот инструмент среди тестировщиков aka инженеров по качеству.
Цель статьи — показать, что для Gherkin'а неверно выбрана целевая аудитория и что стоит начать продвигать этот инструмент среди тестировщиков aka инженеров по качеству.
Любая программа/сценарий/схема ориентирована на того, кто ее писал. Я написал — я понимаю. Написал сосед — понимает сосед.
Проблема — это донести, что ты написал до, бизнеса, разработки, тестера, автотестера.
Геркин в данном случае никак не помогает, но и не мешает. Нужен язык и подход к формированию языка, который поможет быстро донести свою мысль до всех участников.
Геркин тут никак не задает целевую аудиторию, ее задает человек которые придумает базовый синтаксис и словарный запас, обучит этому всех.
И если правило которое задает Геркин(Given, When, Then) понятно команде, то Геркин не поможет вам сформировать дальнейший язык.
Проблема — это донести, что ты написал до, бизнеса, разработки, тестера, автотестера.
Геркин в данном случае никак не помогает, но и не мешает. Нужен язык и подход к формированию языка, который поможет быстро донести свою мысль до всех участников.
Геркин тут никак не задает целевую аудиторию, ее задает человек которые придумает базовый синтаксис и словарный запас, обучит этому всех.
И если правило которое задает Геркин(Given, When, Then) понятно команде, то Геркин не поможет вам сформировать дальнейший язык.
Я правильно понимаю, что реализацию сценариев, написанных на Gherkin, в коде выполняет уже программист, а не тестировщик?
А что мешает взять грамматический фреймфорк, написать нужную себе грамматику и дальше на основе этой грамматики вызывать свое API? И написать можно все так, как хочется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории