Хто ви, які пишуть на 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 тестерів). Навик створення сценаріїв тестування у них в крові. Склад розуму дозволяє виокремлювати найбільш важливі і потрібні сценарії для тестування і легко їх описувати. Ще, це люди, яким згодом належить тестувати майбутню систему. А значить, вони зацікавлені в тому, щоб система, яка до них потрапить — мала чітко визначені специфікації і сценарії поведінки.

Так, це перевертає звичну логіку. Так, тестер починає свою роботу до того, як буде розроблено. Але ж по суті 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?

/>
/>


<input type=«radio» id=«vv70785»
class=«radio js-field-data»
name=«variant[]»
value=«70785» />
Так
<input type=«radio» id=«vv70787»
class=«radio js-field-data»
name=«variant[]»
value=«70787» />
Немає
<input type=«radio» id=«vv70803»
class=«radio js-field-data»
name=«variant[]»
value=«70803» />
Скоріше так, ніж ні
<input type=«radio» id=«vv70805»
class=«radio js-field-data»
name=«variant[]»
value=«70805» />
Швидше ні, ніж так

Проголосувало 32 людини. Утрималося 11 осіб.


На кого по-вашому повинен бути орієнтований Gherkin?

/>
/>

<input type=«radio» id=«vv70789»
class=«radio js-field-data»
name=«variant[]»
value=«70789» />
Команда бізнесу
<input type=«radio» id=«vv70791»
class=«radio js-field-data»
name=«variant[]»
value=«70791» />
Розробники
<input type=«radio» id=«vv70793»
class=«radio js-field-data»
name=«variant[]»
value=«70793» />
Тестувальники
<input type=«radio» id=«vv70795»
class=«radio js-field-data»
name=«variant[]»
value=«70795» />
Свій варіант (пишіть у коментарях)

Проголосувало 23 людини. Утрималося 14 осіб.


Ви використовуєте Gherkin у своїй роботі?

/>
/>

<input type=«radio» id=«vv70797»
class=«radio js-field-data»
name=«variant[]»
value=«70797» />
Так
<input type=«radio» id=«vv70799»
class=«radio js-field-data»
name=«variant[]»
value=«70799» />
Планую почати
<input type=«radio» id=«vv70801»
class=«radio js-field-data»
name=«variant[]»
value=«70801» />
Немає

Проголосувало 35 осіб. Утрималося-10 чоловік.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.