Практико-ориентированный Agile: шаблон Given-When-Then для документирования требований и тестирования

Шаблон Given-When-Then является Agile-практикой. Он может быть использован в совокупности с другими практиками (инструментами) майндсета Agile (BDD, TDD, ATDD). Используется для написания сценариев приемочных тестов (Acceptance Tests) и критериев приемки (Acceptance Criteria) пользовательских историй (User Stories), а также описания расширенного поведения системы, исходя из пользовательских историй.

Это интересно!

Указанные практики в совокупности с иными (например, Unit Tests, Usability Tests и т.д.) объединяются в так называемый клан (tribe) практик Agile (он называется Testing) для организации процессов гибкого тестирования.

Для глубоко понимающих Agile приведу аналогию c объединением практик в трайб для Scrum, который определяет инструменты уже входящие во фреймворк (Backlog, например) и инструменты, дополняющие гибкую разработку с использованием фреймворка Scrum (Burndown chart, Planning poker, Backlog grooming, например).

Трайб Testing предназначен для обеспечения инструментарием процессов гибкой разработки и гибкого тестирования, которые могут быть реализованы, например, с использованием BDD (или большего количества практик из трайба). Язык Gherkin расширяет шаблон Given-When-Then и является еще более мощным инструментом для реализации BDD.

Приведу подробное описание блоков шаблона.

  • «Given» определяет исходные условия для проведения теста (или для описания желаемого поведения, если инструмент используется бизнес-аналитиками с целью создания спецификации требований или документации);
  • «When» содержит выполнение какого-то действия (трассировка на User Story и потребности стейкхолдеров);
  • «Then» содержит результат выполнения действия при заданных условиях, приносящий пользу (Value) стейкхолдерам.

Например:

Given my bank account is in credit And I made no withdrawals recently

When I attempt to withdraw an amount less than my card’s limit

Then the withdrawal should complete without errors or warnings

Еще примеры приемочных тестов в виде сценариев и критерии приемки см. тут.

Процесс создания приемочных тестов является последним этапом проверки качества пользовательской истории (User Story), ее ценности. Как уже говорилось в предыдущих статьях (см. раздел «Смотрите также» ниже), атрибутом качества или признаком хорошей пользовательской истории является именно возможность написания для нее критериев приемки/приемочных тестов (Acceptance Criteria/Acceptance Tests).

Всю серию статей по BDD можно найти в соответствующей рубрике или по тегам, расположенным под статьей.

Для дальнейшего развития ресурса выберите, пожалуйста, варианты ответов в формах ниже и нажмите кнопки «Vote». Спасибо!

Смотрите также:

  1. Атрибуты качества пользовательских историй (User Stories): модель INVEST от Билла Уэйка (Bill Wake).
  2. 5 признаков хороших пользовательских историй (User Stories) от Робертсонов.
  3. Что такое Gherkin и зачем он нужен бизнес-аналитику?