Пользователь
0,0
рейтинг
13 января в 12:32

Разработка → Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории


Сценарий: Определение причин слабой распространенности 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 это как раз об этом…

И не будет проблем с тем, что:
  1. тестеры должны половину итерации “плевать в потолок”, а потом быстро быстро все прогонять;
  2. тестеры работают по своим собственным, “смещенным”, скажем, на неделю, спринтам.

На конец итерации будет оставаться самая интересная и сложная часть — исследовательское тестирование, на которое редко когда хватает времени при обычной разработке.

Тут возникает вопрос: “Бизнес-аналитика меняем на гибкого тестировщика вооруженного Gherkin что ли?”.
Нет, не меняем. Мы дополняем команду формулирования требований тестировщиком. Для пояснения хочу сослаться на матрицу тестирования:
image
На мой взгляд, Gherkin, явный представитель бизнес-ориентированных тестов, которые поддерживают разработку. Иными словами — это второй квадрант (Q2). Тесты этого квадранта в первую очередь направлены на сбор требований. Как бы мог выглядеть процесс сбора требований, когда у нас есть тестировщик с Gherkin?

В современной разработке новые фичи начинают свою жизнь в виде пользовательских историй, написанных командой бизнеса. Написание историй не подразумевает проработку деталей. Истории предназначены только для того, чтобы служить отправной точкой диалога между командами бизнеса и разработки. Здесь важную роль играют тестировщики, которые помогают выбрать примеры и контекст для каждой пользовательской истории. Именно в этот момент рождаются сценарии Gherkin и появляется общее информационное пространство для всех участников процесса. Понимая проблематику бизнеса, технические специалисты смогут предложить более практичные в реализации альтернативы. Полученные в результате обсуждения сценарии использования (use-cases) одобряются бизнесом. В дальнейшем эти сценарии являются руководством для разработчиков в процессе написания кода и помогают узнать, когда код начинает удовлетворять требованиям бизнеса.

Подведем итог


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

Разработчикам Gherkin скорее не помогает, а заставляет выполнять какие-то дополнительные, возможно, ненужные действия. Для разработчика автоматизацию тестирования проще выполнять в первом квадранте (Q1) матрицы тестирования, на уровне модульных тестов, просто выглядеть они могут в стиле BDD (codeception, mocha.js и т.п.).

Тестировщики, на мой взгляд, оптимальная целевая аудитория для Gherkin. Программируют далеко не все тестировщики, но они смогут довольно легко овладеть Gherkin’ом. На раннем этапе выполняется часть работы по тестированию и остается время для других видов тестирования, например, исследовательского.

Так же хочу отметить, что, на мой взгляд, тесты из квадрантов 1 и 2 (Q1 и Q2) ни в коем случае не должны противопоставляться, они прекрасное дополнение друг к другу!
Тесты первого квадранта дают такой замечательный артефакт, как качественный дизайн программного кода.
Тесты второго квадранта дают уверенность в том, что бизнес получит то, что он ожидает, а не то, что получилось.

А что на этот счет думаете Вы?
Полезен ли Gherkin?

Проголосовал 131 человек. Воздержалось 45 человек.

На кого по-вашему должен быть ориентирован Gherkin?

Проголосовало 106 человек. Воздержалось 59 человек.

Вы используете Gherkin в своей работе?

Проголосовало 146 человек. Воздержалось 37 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Evgeniy Pavlyuk @wizi4d
карма
9,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (18)

  • +2
    Однажды видел (возможно, в виде упоминания на Хабре) интересный вариант применения Gherkin: допустим, первая версия продукта пишется на Ruby в целях ускорения разработки. Для неё пишутся тесты на Gherkin. Затем, когда продукт уже выпущен, набирает пользователей и в целом более-менее устоялся, его начинают переписывать, к примеру, на Java. Тогда надо просто переписать step_definitions с Ruby на Java, а сами сценарии (которых могут быть тысячи) остаются неизменными. Конечно, редкий случай, но для него применение Gherkin весьма полезно.
    • +2
      просто переписать

      Ой как не просто, а с учетом того что ошибки могут быть и в коде определений шагов и в новом приложении на новом языке, это будет довольно сложная работа.
      • 0
        Да, в любом случае это будет сложным процессом. Но в сравнении с переписыванием всех тестовых сценариев количество мест, где можно ошибиться, существенно снижается.
  • 0
    В моем понимании, Gherkin предназначен исключительно для описания поведения системы.

    Скажу сразу — мое понимание может быть не до конца верным, потому что мне почему-то так и не попалось цельное руководство по этому языку, буду очень признателен, если посоветуете какой-нибудь авторитетный материал по этой теме.

    Но если мое понимание верно, то полезность Gherkin для аналитика есть, но она не очень велика, т.к. описание поведения системы — это лишь малая часть того, с чем сталкивается аналитик.

    Для бизнеса полезность еще меньше, т.к. бизнес не умеет и не должен, вообще говоря, уметь разговаривать на формальных языках.
  • +1
    У нас бизнес-аналитики перестали плеваться примерно после того как мы стали писать в сценариях вместо
    я нажимаю на ссылку «войти»
    я ввожу «васяпупкин» в поле мыла
    я ввожу «васяпупкин1111» в поле пароля
    я нажимаю на кнопку «войти»
    я должен увидеть «здравствуйте, Вася Пупкин!»

    что-то вроде этого:
    Я пользователь Вася Пупкин
    • 0
      А что означает последняя фраза «Я пользователь Вася Пупкин»?

      И какой смысл в сценарии:

      КОГДА
      я пользователь Вася Пупкин

      ТОГДА
      я должен увидеть «Здравствуйте, Вася Пупкин!»

      Проще тогда уже написать по-человечески: «После авторизации пользователь видит страницу приветствия, на которой отображается текст: „Здравствуйте, <Имярек>!“

      — как и пишут аналитики в спецификациях.
      • 0
        Если цель фичи — проверить приветствие, то можно написать
        Given Я пользователь Вася Пупкин
        When Я логинюсь
        Then Я должен увидеть приветствие

        Но приветствие это вообще не фича обычно. Я имел ввиду, что мы пишем всякие более высокоуровневые вещи типа
        Я пользователь Вася Пупкин
        У меня баланс $100
        Я покупаю подписку
        У меня баланс должен стать $50

        вместо
        Я нажимаю «логин»

        Я нажимаю «оплатить»

        Я должен увидеть $50
        • 0
          А это реально помогает? Просто сразу приходит на ум пример из реальной жизни:

          Я абонент оператора «Лучшая мобильная связь» со стажем больше 3 лет
          У меня есть набор услуг: сотовая связь, мобильный интернет
          Мой тариф включает различные опции для телефонии и интернета
          Мой кредит составляет 100 рублей

          Если я позвоню своей теще, у которой «дружественный» тарифный план, сколько денег у меня останется на счете через 13 минут разговора, при условии, что мы находимся в разных регионах?

          В данном примере, ограничимся параметрами расчета (тоже все из жизни):

          1. Стаж больше 3 лет? (да, нет)
          2. Программа поощрения абонентов со стажем в настоящий момент действует? (да, нет)
          3. Опции понижающие тариф включены? (да, нет)
          4. Дружественный тариф есть? (да, нет)
          5. Между регионами есть роуминг? (да, нет)

          Итого 32 возможных вариантов исхода при расчете. Не удобнее ли все эти кейсы формализовать одновременно в виде таблицы решений, а не в виде 32 различных WHEN-THEN сценариев?
          • +1
            Конкретно в этом случае я бы не писал 32 варианта, т.к. большинство из опций не влияют друг на друга. Я бы написал отдельно сценарии на конкретные опции и совместил бы где-то, где реально есть влияние. Но таблицы это тоже очень мощный и удобный инструмент задания примеров, в Gherkin они предусмотрены через Schenario Outline / Examples. Мы их активно юзаем тоже для подобных данных, где очень много примеров однотипных. Вопрос тут скорее в том, чтобы по максимуму убирать примеры, которые не интересны бизнесу. Если, например, стаж дает 10% скидку при условии включения программы поощрения, нету смысла делать 10 сценариев со стажем + программой и различными вариантами других опций, потому что знаний никаких в них не добавится, можно сделать просто несколько сценариев со стажем, программой и каким-то фиксированным набором других опций.
            • +1
              Главное при таком отсечении ничего существенного не пропустить :)
              • 0
                Ну смотреть надо конкретно в каждом случае. Алгоритм на всё не придумаешь.
    • 0
      Похоже, что в приведенном примере, бизнес-аналитики прокачали или им помогли прокачать скилл проектирования сценариев тестирования.
      • +2
        Можно и так сказать. Но BDD это скорее не про тестирование. Если у нас простой проект и там все понятно в требованиях, то просить BA писать эти сценарии бессмысленно — действительно, с этим лучше справятся QA. Но все меняется, когда требования сложные. Тут сценарии помогают их описывать и обсуждать намного проще, чем всякие спеки, описывающие требования. И как byproduct мы имеем пак приемочных тестов.
  • +4
    О чем постоянно твердят люди, продвигающие BDD. Сценарии это не тесты. Сценарии это способ обмена знаниями. Сценарий позволяет с бОльшей уверенностью сказать, что все участники понимают систему одинаково. Позволяют всем общаться на одном и том же языке. Автотесты это приятное дополнение.
    • +1
      А некоторые, вообще говорят, что тестов не существует, а есть проектирование поведения.
      • 0
        Я так говорю ;-)

        у меня даже табличка есть: на стене висит.

        Почему тестов нет?

        потому что важны не тесты, а проверка качества

        Функциональные тесты => Функциональное поведение => Качество поведения функций системы
        Модульные тесты => Модульное поведение => Качество поведения модулей системы
        Покрытия кода тестами => Покрытие кода поведением => Контроль поведения кода



        и т.д.

        Нужно читать первоисточник — то есть Аслака, Мэта и остальных. cucumber.pro в общем.

        Исходя из парадигмы «тестов нет» мне удобней решать проблемы следующего характера:

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

        И вообще я сейчас при внедрении практик основываюсь на имплементации контроля качества как это рекомендуется методологами

        * www.scaledagileframework.com/built-In-quality
        * www.scaledagileframework.com/story

        однако так как авторы SAFe только разрабатывают виденье по Gherkin и концепцию BDD совместно с cucumber, приходится делать машап:

        * SAFe + Example Mapping cucumber.io/blog/2015/12/08/example-mapping-introduction

        ну и конечно подглядывать к SpecLog www.speclog.net

        с закосом под 1С конечно.

        Кстати EvilBeaver вот тебе прикол из последнего.

        При анализе feature файлов по результатам одного проекта было выявлено что средняя длина шагов сценариев 8. Ну вот так они делали — Сценария с 8-ью шагами. А были даже с 16-ью. А были с 36-тью.

        Пользовались «гады» функционалом «feature файлы из воздуха» и фактически отразили какая у них 1С вот этот функционал имеется ввиду (https://youtu.be/SdCdinDUocA?list=PL2zlgf113YhFG_uRARjDtP1_Obj55UmY4)

        Поступила задача от заказчика повысить эргономичность решения — именно так вот абстрактно. Взять и повысить.

        А как понять менеджеру продукта, чего и где повысить — эргономисты берут за проекты по повышению эргономичности милионы денег.

        Так вот взяли и построили простую статистику

        Группа фич — Фича — Сценарий — Количество шагов

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

        Согласно Google исследования и Yandex исследованиям ( а так же на форумах всяких там Morae и Tobie) есть целевой показатель — «Любую операцию эргономично выполнять в 3 действия и не больше».

        Поэтому глобальная задача по повышению эргономичности выродилась в:

        * взять самый большой сценарий поведения
        * разбить на несколько сценариев по 3 шага в каждом
        * основной сценарий сделать высокоуровневым с вызовом вложенных сценариев.

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

        wizi4d пропустил твою статью — получилось классно, хотя и холиварно. Жаль что тебя Gherkin не впечатлил в итоге — хотя вроде же вместе начинали ;-). Похоливарю с тобой немного — www.youtube.com/watch?v=hy_XCXZTyyw.
        • 0
          Не знаю, почему ты решил, что Gherkin меня не впечатлил. Я вполне нормально к нему отношусь и очень даже вижу область его применения.
          Цель статьи — показать, что для Gherkin'а неверно выбрана целевая аудитория и что стоит начать продвигать этот инструмент среди тестировщиков aka инженеров по качеству.
  • 0
    Любая программа/сценарий/схема ориентирована на того, кто ее писал. Я написал — я понимаю. Написал сосед — понимает сосед.
    Проблема — это донести, что ты написал до, бизнеса, разработки, тестера, автотестера.
    Геркин в данном случае никак не помогает, но и не мешает. Нужен язык и подход к формированию языка, который поможет быстро донести свою мысль до всех участников.
    Геркин тут никак не задает целевую аудиторию, ее задает человек которые придумает базовый синтаксис и словарный запас, обучит этому всех.

    И если правило которое задает Геркин(Given, When, Then) понятно команде, то Геркин не поможет вам сформировать дальнейший язык.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.