Сценарий: Определение причин слабой распространенности Gherkin
Допустим я решил разобраться, почему Gherkin используется небольшим количеством команд
Когда начал анализ причин
Тогда понял, что неверно выбрана целевая аудитория
Не так давно среди моих знакомых возник вопрос: “Зачем Gherkin?”. Причем вопрос был поставлен не как вброс на лопате, а чтобы понять его применимость.
Старт обсуждению дал kuntashov в G+ заметкой со следующим содержанием (сюда я привожу сухой остаток, совсем немного подкорректированный мной):
Gherkin был создан, чтобы сценарии использования можно было редактировать как нарратив (повествование), т.е. “почти на человеческом языке” в простой, лаконичной форме и доступном формате. Т.е. назначение формата было — быть в первую очередь лицом к не-технарям, но при этом сохранить более-менее достаточную формальность, чтобы можно было автоматически обрабатывать.
При этом бизнес-аналитики или любые другие конечные пользователи не очень хотят читать и тем более редактировать сценарии на Gherkin. Таким образом создание feature файлов перекладывается на плечи разработчика, для которого Gherkin — дополнительный и, возможно, лишний слой абстракции. Как мы знаем, “абстракции текут” и дополнительный слой только увеличивает вероятность “протечки”.
Может все же использовать языки, которые больше повернуты лицом к программистам?
Если есть желание совместно разобраться в полезности Gherkin и для кого он предназначен, добро пожаловать под кат.
Подчеркну, что Gherkin = BDD, но BDD ? Gherkin.
Действительно, если посмотреть на инструментарий поддерживающий BDD концепцию, сразу становится видно, что есть 2 выделенных лагеря:
- те, кто описывает поведение на Gherkin и затем делает маппинг с языком разработки. Например, Cucumber, SpecFlow и т.п.
- те, кто описывает поведение сразу на языке разработки, но в более естественной форме, нежели привычный код. Например, Codeception, mocha.js и т.п.
Gherkin, если кто не знает, это язык описания желаемого поведения системы. В виду своей близости к естественному языку, прослеживается попытка убить сразу двух зайцев — автоматизировать тестирование и создать “живую” проектную документацию. Те, кто хочет узнать подробнее — жмукаем сюда (eng) или сюда (rus).
Gherkin и представители бизнеса / аналитики
Изначально Gherkin позиционировался как инструмент для аналитиков и представителей бизнеса. Немного поясню, что под представителями бизнеса я понимаю бизнес-экспертов, владельцев продуктов, аналитиков, экспертов предметной области и т.п.
Почему же он не едет?
Не смотря на максимальную приближенность Gherkin к человеческому языку, это все же язык программирования. Т.е. мы просим бизнес немного попрограммировать… Как большинство людей поступает, когда их просят делать что-то, в чем они не особо разбираются и, по большому счету, не должны разбираться? Прокрастинируют или бунтуют.
Gherkin и разработчики
Итак, определились. Представители бизнеса описывать формальные сценарии, как правило, не могут и не хотят. Хорошо, перекинем это на плечи разработчиков.
Почему и тут не едет?
Дело в том, что у подавляющего большинства разработчиков мозг устроен так, что у них когнитивное сопротивление против написания тестов до кода. Я помню свои ощущения, когда начал пробовать TDD. Абсолютно ломается привычный способ мышления, было такое ощущение, что у меня меняются местами левая и правая половинки мозга… КАК? КАК я могу тестировать то, что еще не написано!?!?!? Только после перестроения мышления такой подход начинает ощущаться как естественный и начинает приносить пользу.
Более того, далеко не все разработчики умеют проектировать сценарии тестирования. Проектирование сценария тестирования — это особый процесс, который так же не является естественным для разработчиков. Разработчики — творцы, которым не до вопросов валидации и верификации.
Стоит так же обратить внимание на абсолютно логичное замечание, что Gherkin — это дополнительный слой абстракции для разработчиков. Зачем мне что-то писать на Gherkin, если я могу сразу на прикладном языке все сделать? Конечно, Gherkin для разработчиков выглядит как совершенно лишнее звено.
Gherkin и someone else?
Хорошо, представители бизнеса не могут / не хотят, разработчики не могут / не хотят. Так для кого был придуман этот инструмент? Кому он может быть полезен?
Может проблема кроется в неправильном позиционировании и неправильном выборе целевой аудитории?
А что если предположить, что целевая аудитория Gherkin — это тестировщики? Причем не просто тестировщики, а гибкие тестировщики (agile testers). Навык создания сценариев тестирования у них в крови. Склад ума позволяет вычленять самые важные и нужные сценарии для тестирования и легко их описывать. Еще, это люди, которым впоследствии предстоит тестировать будущую систему. А значит, они заинтересованы в том, чтобы система, которая к ним попадет — имела четко заданные спецификации и сценарии поведения.
Да, это переворачивает привычную логику. Да, тестер начинает свою работу до того, как что-то будет разработано. Но ведь по сути TDD и BDD это как раз об этом…
И не будет проблем с тем, что:
- тестеры должны половину итерации “плевать в потолок”, а потом быстро быстро все прогонять;
- тестеры работают по своим собственным, “смещенным”, скажем, на неделю, спринтам.
На конец итерации будет оставаться самая интересная и сложная часть — исследовательское тестирование, на которое редко когда хватает времени при обычной разработке.
Тут возникает вопрос: “Бизнес-аналитика меняем на гибкого тестировщика вооруженного Gherkin что ли?”.
Нет, не меняем. Мы дополняем команду формулирования требований тестировщиком. Для пояснения хочу сослаться на матрицу тестирования:
На мой взгляд, Gherkin, явный представитель бизнес-ориентированных тестов, которые поддерживают разработку. Иными словами — это второй квадрант (Q2). Тесты этого квадранта в первую очередь направлены на сбор требований. Как бы мог выглядеть процесс сбора требований, когда у нас есть тестировщик с Gherkin?
В современной разработке новые фичи начинают свою жизнь в виде пользовательских историй, написанных командой бизнеса. Написание историй не подразумевает проработку деталей. Истории предназначены только для того, чтобы служить отправной точкой диалога между командами бизнеса и разработки. Здесь важную роль играют тестировщики, которые помогают выбрать примеры и контекст для каждой пользовательской истории. Именно в этот момент рождаются сценарии Gherkin и появляется общее информационное пространство для всех участников процесса. Понимая проблематику бизнеса, технические специалисты смогут предложить более практичные в реализации альтернативы. Полученные в результате обсуждения сценарии использования (use-cases) одобряются бизнесом. В дальнейшем эти сценарии являются руководством для разработчиков в процессе написания кода и помогают узнать, когда код начинает удовлетворять требованиям бизнеса.
Подведем итог
Для команды бизнеса Gherkin может быть полезен только если в команде есть специалист, разбирающийся в технологиях и с задатками программиста.
Разработчикам Gherkin скорее не помогает, а заставляет выполнять какие-то дополнительные, возможно, ненужные действия. Для разработчика автоматизацию тестирования проще выполнять в первом квадранте (Q1) матрицы тестирования, на уровне модульных тестов, просто выглядеть они могут в стиле BDD (codeception, mocha.js и т.п.).
Тестировщики, на мой взгляд, оптимальная целевая аудитория для Gherkin. Программируют далеко не все тестировщики, но они смогут довольно легко овладеть Gherkin’ом. На раннем этапе выполняется часть работы по тестированию и остается время для других видов тестирования, например, исследовательского.
Так же хочу отметить, что, на мой взгляд, тесты из квадрантов 1 и 2 (Q1 и Q2) ни в коем случае не должны противопоставляться, они прекрасное дополнение друг к другу!
Тесты первого квадранта дают такой замечательный артефакт, как качественный дизайн программного кода.
Тесты второго квадранта дают уверенность в том, что бизнес получит то, что он ожидает, а не то, что получилось.
А что на этот счет думаете Вы?
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (16)
PavelSandovin
13.01.2016 15:14В моем понимании, Gherkin предназначен исключительно для описания поведения системы.
Скажу сразу — мое понимание может быть не до конца верным, потому что мне почему-то так и не попалось цельное руководство по этому языку, буду очень признателен, если посоветуете какой-нибудь авторитетный материал по этой теме.
Но если мое понимание верно, то полезность Gherkin для аналитика есть, но она не очень велика, т.к. описание поведения системы — это лишь малая часть того, с чем сталкивается аналитик.
Для бизнеса полезность еще меньше, т.к. бизнес не умеет и не должен, вообще говоря, уметь разговаривать на формальных языках.
m00t
13.01.2016 17:02+1У нас бизнес-аналитики перестали плеваться примерно после того как мы стали писать в сценариях вместо
я нажимаю на ссылку «войти»
я ввожу «васяпупкин» в поле мыла
я ввожу «васяпупкин1111» в поле пароля
я нажимаю на кнопку «войти»
я должен увидеть «здравствуйте, Вася Пупкин!»
что-то вроде этого:
Я пользователь Вася Пупкин
PavelSandovin
13.01.2016 18:15А что означает последняя фраза «Я пользователь Вася Пупкин»?
И какой смысл в сценарии:
КОГДА
я пользователь Вася Пупкин
ТОГДА
я должен увидеть «Здравствуйте, Вася Пупкин!»
Проще тогда уже написать по-человечески: «После авторизации пользователь видит страницу приветствия, на которой отображается текст: „Здравствуйте, <Имярек>!“
— как и пишут аналитики в спецификациях.m00t
13.01.2016 18:32Если цель фичи — проверить приветствие, то можно написать
Given Я пользователь Вася Пупкин
When Я логинюсь
Then Я должен увидеть приветствие
Но приветствие это вообще не фича обычно. Я имел ввиду, что мы пишем всякие более высокоуровневые вещи типа
Я пользователь Вася Пупкин
У меня баланс $100
Я покупаю подписку
У меня баланс должен стать $50
вместо
Я нажимаю «логин»
…
Я нажимаю «оплатить»
…
Я должен увидеть $50
PavelSandovin
14.01.2016 16:19А это реально помогает? Просто сразу приходит на ум пример из реальной жизни:
Я абонент оператора «Лучшая мобильная связь» со стажем больше 3 лет
У меня есть набор услуг: сотовая связь, мобильный интернет
Мой тариф включает различные опции для телефонии и интернета
Мой кредит составляет 100 рублей
Если я позвоню своей теще, у которой «дружественный» тарифный план, сколько денег у меня останется на счете через 13 минут разговора, при условии, что мы находимся в разных регионах?
В данном примере, ограничимся параметрами расчета (тоже все из жизни):
1. Стаж больше 3 лет? (да, нет)
2. Программа поощрения абонентов со стажем в настоящий момент действует? (да, нет)
3. Опции понижающие тариф включены? (да, нет)
4. Дружественный тариф есть? (да, нет)
5. Между регионами есть роуминг? (да, нет)
Итого 32 возможных вариантов исхода при расчете. Не удобнее ли все эти кейсы формализовать одновременно в виде таблицы решений, а не в виде 32 различных WHEN-THEN сценариев?m00t
14.01.2016 16:31+1Конкретно в этом случае я бы не писал 32 варианта, т.к. большинство из опций не влияют друг на друга. Я бы написал отдельно сценарии на конкретные опции и совместил бы где-то, где реально есть влияние. Но таблицы это тоже очень мощный и удобный инструмент задания примеров, в Gherkin они предусмотрены через Schenario Outline / Examples. Мы их активно юзаем тоже для подобных данных, где очень много примеров однотипных. Вопрос тут скорее в том, чтобы по максимуму убирать примеры, которые не интересны бизнесу. Если, например, стаж дает 10% скидку при условии включения программы поощрения, нету смысла делать 10 сценариев со стажем + программой и различными вариантами других опций, потому что знаний никаких в них не добавится, можно сделать просто несколько сценариев со стажем, программой и каким-то фиксированным набором других опций.
wizi4d
14.01.2016 09:16Похоже, что в приведенном примере, бизнес-аналитики прокачали или им помогли прокачать скилл проектирования сценариев тестирования.
m00t
14.01.2016 10:23+2Можно и так сказать. Но BDD это скорее не про тестирование. Если у нас простой проект и там все понятно в требованиях, то просить BA писать эти сценарии бессмысленно — действительно, с этим лучше справятся QA. Но все меняется, когда требования сложные. Тут сценарии помогают их описывать и обсуждать намного проще, чем всякие спеки, описывающие требования. И как byproduct мы имеем пак приемочных тестов.
m00t
14.01.2016 16:36+4О чем постоянно твердят люди, продвигающие BDD. Сценарии это не тесты. Сценарии это способ обмена знаниями. Сценарий позволяет с бОльшей уверенностью сказать, что все участники понимают систему одинаково. Позволяют всем общаться на одном и том же языке. Автотесты это приятное дополнение.
EvilBeaver
14.01.2016 19:14+1А некоторые, вообще говорят, что тестов не существует, а есть проектирование поведения.
sirmakc
18.01.2016 12:06Любая программа/сценарий/схема ориентирована на того, кто ее писал. Я написал — я понимаю. Написал сосед — понимает сосед.
Проблема — это донести, что ты написал до, бизнеса, разработки, тестера, автотестера.
Геркин в данном случае никак не помогает, но и не мешает. Нужен язык и подход к формированию языка, который поможет быстро донести свою мысль до всех участников.
Геркин тут никак не задает целевую аудиторию, ее задает человек которые придумает базовый синтаксис и словарный запас, обучит этому всех.
И если правило которое задает Геркин(Given, When, Then) понятно команде, то Геркин не поможет вам сформировать дальнейший язык.
HedgeSky
Однажды видел (возможно, в виде упоминания на Хабре) интересный вариант применения Gherkin: допустим, первая версия продукта пишется на Ruby в целях ускорения разработки. Для неё пишутся тесты на Gherkin. Затем, когда продукт уже выпущен, набирает пользователей и в целом более-менее устоялся, его начинают переписывать, к примеру, на Java. Тогда надо просто переписать step_definitions с Ruby на Java, а сами сценарии (которых могут быть тысячи) остаются неизменными. Конечно, редкий случай, но для него применение Gherkin весьма полезно.
Vass
Ой как не просто, а с учетом того что ошибки могут быть и в коде определений шагов и в новом приложении на новом языке, это будет довольно сложная работа.
HedgeSky
Да, в любом случае это будет сложным процессом. Но в сравнении с переписыванием всех тестовых сценариев количество мест, где можно ошибиться, существенно снижается.