Про Gherkin слышали в основном те, кто связан с тестированием. Среди аналитиков он встречается крайне редко. Но если отбросить всё связанное с BDD и тестами, то Gherkin это формат описания поведения системы, где сценарий это обычный текст, написанный в структурированном виде “Given‑When‑Then”. Не код, не диаграмма, а короткое текстовое описание того, что происходит в системе в определённых условиях.
Не потому что модно, не потому что “так надо”, а потому что это удобно. Можно описать фактически всё: контекст, событие, результат - в трёх строках. Удивительно, что это не стало стандартом. Но как это работает на практике? Чтож… Щас выскажусь!
Откуда вообще этот Gherkin?
Gherkin придумали ребята из Cucumber, чтобы писать автотесты в виде сценариев, читаемых человеком. Сценарий всегда начинается с условия (Given), действия (When) и результата (Then). Добавили возможность использовать And и But, чтобы не повторяться. Всё это сделано для того, чтобы описания были понятны не только разработчику, но и аналитику, тестировщику и бизнесу.
Сама по себе структура Given‑When‑Then - это просто формат. Она не требует никакой привязки к тестированию или к процессу разработки. Хочешь - используешь как шаблон для документации. Хочешь - как язык общения с командой. Варианты использования зависят только от тебя.
BDD - это не про аналитику? И ладно
Behavior-Driven Development звучит красиво, но в реальности редко бывает внедрено полноценно. Особенно в компаниях, где процессы смешаны, а требования размыты.
Системный аналитик в BDD-процессы попадает редко или не попадает вообще. Мы пишем требования, согласовываем поведение, разбираем интеграции и готовим спецификации. И это нормально!
Но из этого не следует, что Gherkin не для нас. Наоборот если отбросить тестовую часть и оставить только структуру описания, то Given‑When‑Then оказывается удобным инструментом именно для аналитика. Просто берёшь эту форму и начинаешь использовать её для описания.
Почему Gherkin - это просто хороший способ описывать поведение
Суть в том, что он заставляет писать логично и по структуре. Вместо абстрактных «если пользователь что-то сделал, то должно что-то произойти» ты вынужден задать себе три вопроса:
Какой контекст должен быть до действия? (Given)
Что конкретно происходит? (When)
Какой результат должен наступить? (Then)
Такая форма помогает структурировать мысль. Даже если ты не пишешь сценарий, а просто обсуждаешь поведение системы, Gherkin убирает двусмысленность. Он чётко разделяет “что было, что произошло и к чему это привело”.
Как это работает на практике
Допустим, что у нас есть типичная задача: при регистрации пользователь указывает номер телефона. Если такой номер уже есть в системе, его нельзя зарегистрировать повторно.
Вот как это могут описывать в документации:
Если номер телефона уже зарегистрирован, система должна выдать ошибку.
На первый взгляд вроде бы понятно. Но что именно происходит? Где начинается сценарий? Что делает пользователь? Когда возникает ошибка? В каком виде она отображается? Всё это не раскрыто.
Теперь перепишем это в формате Gherkin:
Given в системе уже существует аккаунт с номером телефона +7 999 000 00 00
When пользователь вводит этот номер и нажимает кнопку "Зарегистрироваться"
Then система отображает сообщение "Такой номер уже используется"
Вместо обобщений мы получаем конкретику:
Чёткий контекст: номер уже есть в базе.
Конкретное действие: пользователь нажимает кнопку.
Ожидаемый результат: сообщение об ошибке.
Такой сценарий можно сразу отдать разработчику или в тестирование. Он читаемый, его легко проверить, и главное - он задаёт единый фокус. Не «ошибка где-то», а конкретное сообщение в конкретной ситуации.
Это хорошо ложится в мышление. Когда привыкаешь думать в Given‑When‑Then, ты по-другому смотришь на поведение системы. Не как на функции, а как на сценарии. А это уже гораздо ближе к реальности.
Немного нестандартного использования
Одна из сильных сторон Gherkin - это гибкость. Его не обязательно использовать строго по шаблону с одной строкой на блок. Иногда сценарий требует более подробного контекста, нескольких условий и нескольких реакций со стороны системы. Всё это легко описывается через And.
Пример из реальной задачи:
Given у пользователя есть три активных заказа
And один из них находится в статусе "ожидание оплаты" дольше 24 часов
When пользователь открывает личный кабинет
Then система выделяет просроченный заказ визуально
And отображает уведомление "У вас есть неоплаченный заказ"
Такая форма позволяет детализировать поведение. Мы по-прежнему видим, где начинается сценарий, какое событие его запускает и какие последствия оно вызывает, но при этом сохраняем читаемость и структуру.
Возможные подводные камни
Gherkin простой и гибкий, но не значит, что его нельзя испортить. Вот несколько нюансов, о которые легко споткнуться:
Забывать, что это не рассказ. Это структура, а не повествование. Чем суше и чётче формулировка тем лучше. «Пользователь разочарованно жмёт на кнопку» - явно не сюда.
Подменять логику интерфейсом. Then - это про результат, а не про то, где и как расположена кнопка. Если описание уходит в верстку, сценарий теряет смысл.
Прыгать между стилями. Если в одном сценарии пишешь "пользователь нажимает", а в другом "юзер кликает" или "клиент взаимодействует", читаемость падает. Gherkin работает, когда структура и терминология одинаковы по всей документации.
Увлекаться вложенностью. Чем длиннее сценарий, тем выше шанс, что его никто не дочитает. Лучше разбить на два сценария, чем городить один с кучей условий и развилок.
Gherkin не заменяет здравый смысл. Если структура помогает - отлично. Если мешает - не надо ломать логику под формальные блоки.
Актуален ли Gherkin сегодня
Если честно, то Gherkin - это не хайп, не стандарт и точно не то, что регулярно обсуждают. Это просто рабочий инструмент. Но если смотреть со стороны пользы, то он вполне живой даже в 2025 году.
Он актуален не потому, что все вокруг его используют, а потому что иногда это лучший способ донести сценарий до команды. Особенно в тех местах, где нужно фиксировать поведение системы внятно и без раздутых описаний с кучей списков и условий. .Вопрос не в моде, а в применимости.
Поэтому да - Gherkin актуален. Не как модная методика, а как один из способов структурирования без лишней воды. Он не решает за тебя, как анализировать. Но он помогает нормально изложить, что ты проанализировал.
Какой итог
Не каждый подход обязан быть частью методологии. Иногда это просто способ думать яснее. Gherkin не требует от тебя что-то менять. Он просто помогает изложить поведение системы как цепочку причин и последствий.
Если ты системный аналитик и тебе нужно передавать логику, а не философствовать про «пользовательский путь» - этот формат работает отлично. А всё, что не работает - идёт “в стол” вместе с очередным недочитанным ТЗ.
Я веду свой ТГ канал #ЯЖАНАЛИТИК, в котором рассказываю о буднях системного аналитика, околоITшной жизни, описываю кейсы, лайфхаки, рабочие неудачи и все то , что тебе потребуется для работы. Простым и доступным языком. Без нудятины и духоты (ну может быть совсем чуть-чуть)
