Към съдържанието
wannacode

Жива документация

Накратко: Документът на Word остарява тихо. Сценариите се пускат при всяка промяна и падат, щом системата спре да прави това, което пише в тях: това е живата документация. Пишат се преди работата, от трите амиго: бизнес, програмист и QA. BDD е този разговор. Сценарии, писани от QA сам след кода, са обикновени тестове с повече работа.

Проблем

Документът, който лъже тихо

Нов човек в екипа отваря спецификацията на доставката. Документ на Word, от преди две години. Пише: „безплатна доставка над 40 €“.

Магазинът дава безплатна доставка от 50 €. Някой е сменил правилото, но не и документа. Никой не е забелязал, защото документът не прави нищо: той само стои.

Новият човек сега не знае кое е вярното: документът или системата?

Идеята

Документация, която се пуска

Сценариите от този модул са и документ, и тест. Ако правилото се смени в системата, но не и в сценария, сценарият пада още при следващото пускане. Ако се смени в сценария, но не и в системата, също пада. Двете не могат да се разминат тихо.

Това се нарича жива документация (living documentation). Тя е жива при едно условие: сценариите се пускат при всяка промяна, обикновено автоматично. Сценарии, които никой не пуска, остаряват точно като документа на Word.

За да е документация, файлът трябва и да се чете като такава:

  • Функционалност казва какво описва файлът, а под нея може да стои самото стори;
  • Правило е всяко бизнес правило, с думите на собственика;
  • под всяко правило са примерите: сценарии и рамки с конкретни числа.
# language: bg
Функционалност: Безплатна доставка
  Като клиент
  искам безплатна доставка при по-голяма поръчка,
  за да не плащам 4,90 € за доставка.


  Правило: Празна количка не се поръчва


    Пример: Количка без продукти
      Дадено празна количка
      Когато поръчам
      То поръчката е отказана

Текстът под „Функционалност“ не е стъпка. Той е описание: Gherkin го пропуска при пускането, а човекът го чете.

Идеята

Кой ги пише и кога

Сценариите не ги пише един човек сам. Те излизат от разговор на трима, които вече срещна на Example Mapping. Наричат ги трите амиго (three amigos):

  • бизнесът (собственикът или анализаторът) казва правилата и какво е важно;
  • програмистът пита как ще се направи и какво от това е трудно;
  • QA пита „а ако…?“: границите, празната количка, отказа.

И кога? Преди работата. Сценарият, писан преди кода, казва какво се иска. Сценарият, писан след кода, описва какво е направено, грешките включително.

Документацията на Cucumber нарича трите стъпки откриване (discovery: разговор за конкретни примери), формулиране (formulation: примерите се записват така, че да се пуснат, и бизнесът потвърждава) и автоматизация (automation: програмистът връзва стъпките със системата). Третата стъпка има свой модул по-нататък.

Пробвай

От сторито до документа

Подреди пътя от сторито до живата документация.

  1. Програмистът връзва стъпките и прави функционалността
  2. Собственикът носи сторито
  3. При всяка следваща промяна сценариите се пускат отново
  4. Бизнесът чете сценариите и казва „да, това е“
  5. Примерите се записват като сценарии на Gherkin
  6. Сценариите минават и сторито е готово
  7. Трите амиго подреждат правила, примери и въпроси

Идеята

BDD срещу „тестове на Gherkin“

Всичко това има име: BDD (behaviour-driven development), разработка, водена от поведението. Важната част на BDD не е Gherkin. Важна е тази последователност: разговор, примери, после код.

Много екипи взимат само синтаксиса. QA пише сценариите сам, след кода, с „натисни бутона“. Бизнесът никога не ги чете. Това са тестове на Gherkin: обикновени автоматични тестове, с още един слой отгоре, който трябва да се поддържа. Цената на BDD е платена, а ползата я няма.

Признаци, че е така:

  • никой от бизнеса не е чел сценариите;
  • сценариите се пишат след кода;
  • стъпките са за бутони и полета, не за правила;
  • сценариите се поправят, когато падат, без въпрос дали системата не е сбъркала.

Ако няма разговор, честният избор е обикновен тест на ниво компонент. Той е по-бърз и по-евтин. Gherkin си струва, когато бизнесът наистина чете сценариите.

Пробвай

BDD или не?

1. QA пише сценариите сам, след като програмистът е свършил. Никой от бизнеса не ги чете.
2. Собственикът, програмистът и QA обсъждат примерите преди работата. Сценариите излизат от срещата и собственикът ги потвърждава.
3. Екипът пише сценарии преди кода, но всичките са „натисни бутона“ и „отвори страницата“.
4. Сценариите се пускат само ръчно, веднъж в годината.

Упражнение

Документът за доставката

Цялата функционалност. Сторито и правилата са написани.

Сложи под всяко правило примерите, които го показват: около границата, далеч от нея и празната количка. Документът трябва да хване всичките шест грешки.

GherkinБезплатна доставка
По-точно, за любопитните

ISTQB CTFL v4.0.1. Раздел 2.1.3 („Testing as a Driver for Software Development“) поставя TDD, ATDD и BDD един до друг: и трите пишат тестовете преди кода и прилагат принципа за ранно тестване. За BDD казва, че тестовите случаи са на прост естествен език, разбираем за заинтересованите страни, обикновено Given/When/Then, и после се превръщат в автоматични тестове. Раздел 4.5.3 описва ATDD (acceptance test-driven development): работилница по спецификацията, на която сторито и критериите се обсъждат заедно (клиент, програмист, тестер), после тестовите случаи, първо положителните, после отрицателните, после нефункционалните. Когато са във формат, който инструментът за автоматизация разбира, приемните тестове стават изпълними изисквания.

ISTQB CT-AcT v1.0 (приемно тестване) има глава за приемното тестване в сътрудничество („Collaborative Acceptance Testing“) и разглежда критериите за приемане и приемните тестове като общата работа на бизнес анализа и тестването.

Дан Норт описва BDD в статията „Introducing BDD“, публикувана първо в списание Better Software през март 2006 г. В нея той и Крис Матс правят шаблон за критериите за приемане като сценарии: Given (началото), When (събитието), Then (резултатите).

Трите амиго. Името се ползва широко в Agile общността. Често се свързва с Джордж Динуиди, но не намерихме първоизточник, който да го потвърди.

Документацията на Cucumber („Behaviour-Driven Development“) описва трите практики: Discovery, Formulation и Automation.

Тест

Провери се

1. Какво прави сценариите „жива“ документация?
2. Кои са трите амиго?
3. Кога се пишат сценариите в BDD?
4. Какво е ATDD по ISTQB CTFL v4.0.1?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·