Требования на Примерах

Есть две бесконечные вещи: Вселенная и человеческая глупость. Впрочем, насчёт первой я не уверен.
--Альберт Эйнштейн

Требования на Примерах (Specification by Example) или разработка через приёмочное тестирование (A-TDD) - это подход совместного выявления требований, в котором примеры и автотесты используются для определения требований, тем самым создавая исполняемые спецификации. Такие спецификации создаются командами вместе с Владельцем Продукта и другими заинтересованными лицами на совместных сессиях по сбору требований.

Заметка по терминологии: Мы будем использовать как и A-TDD, так и Требования на Примерах.

A-TDD объединяет следующие основные идеи:

  • тесты как требования, требования как тесты
  • совместные сессии по прояснению требований
  • одновременная разработка
  • предотвращение вместо обнаружения

Тесты как требования, требования как тесты — В книге Exploring Requirements: Quality before Design её авторы Дональд Гаус и Джеральд Вайнберг исследуют связь между требованиями и тестами: “Одним из самых эффективных способов тестирования требований являются тест-кейсы, очень похожие на те, что используются для тестирования готовой системы”. Григорий Мельник и Боб Мартин далее расширяют это и утверждают: “Если формализовать данное утверждение, тесты и требования становятся неразличимыми. В пределе тесты и требования равнозначны”. Тесты должны быть настолько чёткими, чтобы их можно было автоматизировать. A-TDD использует это утверждение и формулирует требования путём написания автоматизируемых тестов.

Совместные сессии по прояснению требований — Шестой принцип гибкой Разработки ПО напоминает нам: “Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.” Непосредственное прояснение требований во время совместных сессий использовалось с момента изобретения Joint Application Design (JAD). И также используется в Rapid Application Development (RAD) и методе гибкой разработке - DSDM. A-TDD так же использует непосредственное общение во время совместных сессий по формированию тестов в виде требований.

Одновременная разработка — Авторы книги Concurrent Engineering Effectiveness определяют одновременное проектирование так: “Существует настолько тесная связь между участниками в процессе разработки ПО, что они могут осуществлять большую часть их работы одновременно”. Сокращение времени - основной драйвер одновременной разработки. Двухнедельные итерации слишком малы, поэтому командам нужно идти по пути одновременной работы — последовательная разработка не работает в коротких циклах. Мы видели, как команды изобретают требования на примерах снова и снова, просто потому что они хотели ответить на вопрос: “Как мы могли бы выполнять нашу работу одновременно.”

Предотвращение вместо обнаружения — В одном из первых исследований в книге A Study of the Toyota Production System Сигэо Синго пишет: “Предназначение инспекции должно быть в предотвращении; однако, мы должны изменить наш образ мышления, чтобы инспекция имела данную цель.” Так же, в статье “The Growth of Software Testing” авторы идентифицируют пять периодов эволюции тестирования ПО. Они называют последний период “Период направленный на предотвращение” и стадию “Задавать вопросы, связанные с тестированием… как можно раньше часто важнее для обеспечения качества ПО и экономической эффективности разработки, чем собственно выполнение тестов”. Это в точности то, что требования на примерах стараются сделать. Когда специалисты по тестированию принимают участие в совместной сессии по уточнению требований, они могут задавать вопросы о тестировании, и таким способом улучшать требования и препятствовать появлению дефектов. Всеобщее Управление Качеством (англ. Total Quality Management, TQM) - повлиявшее на Тойоту и бережливую разработку — также продвигает предотвращение вместо обнаружения.

Как работает A-TDD? Иллюстрация ниже даёт общее представление.

atdd.png
Обзор A-TDD

Обзор A-TDD

A-TDD состоит из трёх шагов:

  1. Обсудите требования во время совместной сессии.
  2. Реализуйте требования одновременно в итерации.
  3. Доставьте результат заинтересованным лицам для приёмки.

Обсудите — Требования выявляются путём совместного обсуждения. Его участниками являются кросс-функциональные команды, Владелец Продукта или его представитель и любые заинтересованные лица, кто потенциально может обладать информацией о данных требованиях. Обычный вопрос, который задаётся на таких сессии: “Представьте, что система закончена. Как вы бы использовали её и что ожидали бы от неё?”. Ответом на такой вопрос будут примеры использования, и такие примеры могут быть записаны как тесты, являющиеся требованиями. Фокус на этой совместной сессии должен быть больше на обсуждении и выявлении требований, чем на актуальных тестах.

Реализуйте — В конце сессии, примеры “дистиллированы” в тесты и другие активности, которые нужны, чтобы реализовать требования одновременно. Они включают:

  • создание связующего слоя между тестами и продуктивным кодом (“тестовые библиотеки” и “низкоуровневые таблицы” в Robot Framework или ‘фикстуры’ в Fit)
  • реализация требований, позволяющая тестам успешно выполняться
  • обновление архитектурной и другой внутренней документации согласно рабочему соглашению команды
  • актуализация пользовательской документации
  • проведение дополнительного исследовательского тестирования

Точный список зависит от конкретного продукта, контекста, рабочих соглашений и Критериев Готовности.

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

Более подробное описание A-TDD показано ниже

atdd_clarified.png
A-TDD в деталях

A-TDD шаги хорошо сочетаются с LeSS циклом

atdd_in_iteration.png
Отражения A-TDD шагов в Скраме

Обсудите во время совместной сессии — Перед детализацией требований на Планировании Спринта, они совместно проясняются командой, Владельцем Продукта, и другими заинтересованными лицами.

Реализуйте одновременно — Задачи для реализации тестов/требований создаются во время Планирования Спринта и реализуются в течение итерации. Все активности происходят “примерно в одно и то же время”.

Доставьте для приёмки — Инкремент работающего продукта, успешные приёмочные тесты, поставляются для приёмки заинтересованным лицам и обсуждается с ними на Обзоре Спринта.

Обсудите во время совместной сессии

Эксперименты, связанные с такими сессиями, тесно связаны с экспериментами в разделе “Требования”. Этот раздел покрывает A-TDD темы; раздел “Требования” раскрывает тему совместных сессий более детально. (раздел 7. Requirements & PBIs из книги Practices for Scaling Lean & Agile Development [прим. переводчика])

Обсудите во время Уточнения Бэклога Продукта

Команда и Владелец Продукта ‘инспектируют’ Бэклог Продукта во время Уточнения Бэклога Продукта, чтобы удостовериться, что он находится в хорошей форме. Эта активность включает следующее:

  • Оценить и прояснить недавно добавленные Элементы Бэклога Продукта.
  • Разделить большие элементы на маленькие, что бы они могли быть выбраны для реализации.
  • Прояснить предстоящие элементы, чтобы команда хороша поняла их на уровне, достаточном для реализации.

Прояснение неотложных элементов может быть сделано на совместной сессии в стиле A-TDD. Для ясности, Уточнение Бэклога Продукта состоит не только из A-TDD сессии, но он может быть частью активности по уточнению. Другие активности включают оценку и разбиение элементов на более мелкие.

Прояснение важнее написания тестов

A-TDD служит для совместного прояснения требований. Акцент делается на общении, совместной работе и обучении через примеры и тесты. Цель состоит в улучшении понимания, а тесты являются средством её достижения. Книга с соответствующим названием на эту тему, Bridging the Communication Gap подчёркивает:

[Разработка через приёмочное тестирование] не является техникой программирования: это техника для общения, которая сближает людей, вовлечённых в процесс разработки.

Люди часто так озабочены осязаемыми результатами совместного обсуждения - тестами - поэтому они забывают о нематериальных результатах - обучении. Понимание и ясность требований - это ключевые итоги таких обсуждений по уточнению требований; тесты являются лишь проявлением и отражением этого.

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

Используйте примеры

“Вы можете привести пример?”

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

Например, мы слышим утверждение: “Система должна восстанавливаться после сбоя.” Это непонятно, поэтому мы просим привести примеры, что преображает дискуссию. Это могло бы быть: “Когда мы вытаскиваем кабель, система не должна падать”, что конкретно и понятно. Примеры также используются для дальнейшего прояснения, например, “Как система должна восстановиться, если мы удалим её блок, пока она работает?”

Примеры полезны не только для прояснения требований, но и для прояснения подходов к работе. Например: “Мы никогда не сможем автоматизировать все наши тесты!” - на это утверждение мы бы предложили такой вопрос: “Вы можете привести пример теста, который нельзя автоматизировать?”, и это переносит дискуссию от теории к практике.

examples.png
Примеры

Иллюстрация выше показывает связь между примерами, требованиями и тестами. Во время совместных сессий по уточнению требований, используйте примеры для выработки требований и преобразования их в тесты.

Не ‘оптимизируйте’ совместную сессию по уточнению требований

Когда мы обсуждали A-TDD в одной большой продуктовой группе, они отметили: “Мы улучшили совместную A-TDD сессию. В ней участвуют только трое: Владелец Продукта, Скрам-мастер, и специалист из команды.“ Мы спросили их, как другие члены команды смогут понять требования и реализовать их, и ответ был: “Специалист им расскажет“. Они ‘оптимизировали‘ совместную сессию, повторно внедрив передачу аналитик-команда из традиционного подхода.

Избегайте компьютеров и проекторов на совместной сессии

Компьютеры высасывают жизнь из совместных сессий. Они становятся центром обсуждения. Помимо проверки ссылок с материалами, избегайте необходимости ’оптимизировать’ сессии, вводя его непосредственно в компьютер. Вместо этого…

Находите бизнес-правила в рабочих процессах

Прояснение требований во время совместной сессии часто начинается с абстрактных концептов, и когда приведены примеры, оно переходит к обсуждению конкретных сценариев: ”Пользуясь системой, я выполняю шаг 1, затем шаг 2, и ожидаю Х”.

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

Используйте стены для тестов

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

atdd_wall1.jpg
atdd_wall2.jpg

Используйте табличный формат

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

[Когда документирование требований,] написание, понимание, и раскрытие их происходят одновременно… Табличная нотация является лучшей помощью в ситуациях, подобных данной. Сначала определяют структуры таблицы, убеждаясь, что заголовки покрывают все возможные сценарии, а затем обращают внимание на заполнение отдельных записей в таблице.

Используйте тесты рабочего процесса

Извлечение бизнес-правил и использование тестов на основе данных не всегда возможно или целесообразно. Некоторые требования лучше выражать в виде примера рабочего процесса (пошагового сценария). Также, тесты бизнес-правил на основе данных могут быть часто дополнены примерами рабочего процесса, таким образом, связывая их.

Предупреждение: Когда большая часть ваших тестов это тесты рабочего процесса, то вы, возможно, упустили некоторые бизнес-правила.

Типичный план совместной A-TDD сессии

Из чего состоит A-TDD сессия по уточнению требований? Мы часто используем следующий план:

  1. Вступление — Владелец Продукта приветствует всех в начале сессии и объясняет его цель.
  2. Отбор — команда и Владелец Продукта выбирают элементы из Бэклога продукта, над которыми будут работать.
  3. Обзор — Владелец Продукта или его представитель дают короткий обзор выбранных требований.
  4. Разделение — команда делится на две или три подгруппы, каждая из которых берёт один элемент и начинает набрасывать примеры на досках. Владелец Продукта и его представители перемещаются между подгруппами.
  5. Слияние — подгруппы сходятся на время, чтобы поделиться результатами с остальными.
  6. Повторение — цикл разделение-слияние обычно занимает 30-45 минут. Одна сессия содержит несколько циклов.
  7. Заключение — Владелец Продукта подводит итоги работы. Далее следует краткая рефлексия самой сессии.
  8. Фиксация результатов — участники делают фотографии всех записей и размещают их в вики. Они уже могут сделать выжимку в виде нескольких тестов и оформить их в своём A-TDD инструменте.

Реализуйте одновременно

После того, как требования поняты, они должны быть реализованы. Разные активности, необходимые для реализации, выполняются одновременно. Команда расширяет тесты одновременно с реализацией в коде, написанием документации, обновлением архитектурного описания и так далее.

“Дистиллируйте“ тесты

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

Как “дистиллировать“ тесты из примеров? Вот несколько техник:

  • Дублирование — Удалите дубликаты среди примеров, переписав тесты в другой форме. Например, набор тестов рабочего процесса может быть объединён в тест бизнес-правил. В основном это должно происходить во время совместной сессии.
  • Класс эквивалентности — Некоторые примеры являются частями одних и тех же классов эквивалентности и поэтому будет достаточно оставить один тест. Люди со специализацией в тестировании особенно ценны здесь, так как разделение на классы эквивалентности является классической техникой тестирования.
  • Приёмка — Так как не все примеры обладают одинаковым уровнем важности, спросите Владельца Продукта: “Какой набор примеров вы хотели бы видеть работающими в конце итерации?”

Используйте фасилитаторов и тренеров по A-TDD

A-TDD легко понять, но трудно следовать. Он требует бросить вызов глубоким укоренившимся предположениям и изменяет привычки. Часто для этого необходим (внешний) тренер с опытом в A-TDD и организационных изменениях. Найдите такого тренера.

Важно понимать, что навыки хорошего A-TDD тренера отличаются от таковых у тренера по TDD. Обучение TDD более техническое и сфокусировано на индивидуальных навыках разработчиков, тогда как A-TDD вовлекает команду целиком. В дополнении к техническим навыкам, хороший A-TDD тренер имеет отличные навыки фасилитации.

Используйте A-TDD инструмент

  • Fit (акроним от Framework for Integrated Test [прим. переводчика]), возможно, первый инструмент для A-TDD. Он был разработан Уордом Каннингемом в 2002 году. Fit-тесты состоят из HTML-таблиц, которые выполняются с помощью фрагмента кода, называемого фикстурой. Мика (англ. Micah) and Боб Мартины создали расширение FitNesse, в котором таблицы размещаются в вики. FitNesse также включает Slim (Simple List Invocation Method [прим. переводчика]) — более тонкая модель исполнения, обеспечивающая лучшую переносимость и гибкость для изучения новых синтаксисов тестирования. Больше информации вы можете найти в разделе “Рекомендуем к прочтению“ в конце этого раздела.
  • Robot Framework берёт своё начало в компании Nokia Siemens Networks и был разработан Пеккой Кларком. Он был выпущен в 2008 году. Robot имеет некоторые сходства с Fit такие, как таблично структурированные тесты и связующий код между таблицами и системой. Однако он имеет уникальные пользовательские свойства такие, как многослойные таблицы (ключевые слова пользователей).
  • Cucumber был разработан Аслаком Хэллисейем и вдохновлён Дэном Нортом. Он следует формату дано/когда/тогда (англ. given/when/then) для описания примеров. Cucumber тесты читаются, как предложения в простом тексте.

Не используйте традиционные тестовые инструменты для A-TDD

Некоторые продуктовые группы, с которыми мы работали, пытаются использовать свои традиционные инструменты для тестирования такие, как Lisp скрипты или TTCN для A-TDD. Это неизбежный провал. Почему? Тесты в стиле A-TDD создаются так, чтобы Владелец Продукта или пользователь могли их прочитать и понять. А тесты в виде скриптов в традиционных инструментах создаются для инженеров по тестированию и поэтому не подходят для документирования требований. Почти невозможно вовлечь Владельца Продукта в написание примеров в таком инструменте.

Однако используйте A-TDD инструменты в качестве “обёртки” к традиционным тестовым инструментам

Должны ли вы выкинуть все традиционные тестовые инструменты после перехода на A-TDD? Скорее всего нет.

Продуктовая группа, с которой мы работали, потратила годы на создание скриптового языка для автоматизации тестов. Разработка связующего слоя (тестовых библиотек или фикстур) между A-TDD фреймворком и их системой могла бы занять ещё несколько лет - по большей части это та же самая работа, которую они уже проделали со своим скриптовым языком.

Альтернативой было бы обернуть связующим кодом их тестовый скриптовый язык и тем самым повторно использовать проделанную ранее работу. Традиционные инструменты не обязательно плохи, но они обеспечивают неверный формат - неверный язык - для исполняемых спецификаций.

Доставьте для приёмки

Исходный код написан и все тесты пройдены. Что дальше? A-TDD, как и Скрам, содержит цикл инспекции-адаптации, когда результаты доставляются заинтересованным лицам, которые инспектируют итоги, используя тесты, и принимают решения, как действовать дальше - какие требования реализовать следующими.

Показывайте тесты на Обзоре Спринта

На Обзоре Спринта команды демонстрируют видимый прогресс Владельцу Продукта, показывая результаты итерации.

Мы работали с некоторыми продуктовыми группами, которые определяли, как они будут показывать инкремент, ещё на Планировании Спринта. Команда тратила чрезмерное количество времени на подготовку к демонстрации. Это чистые потери.

Во время Планирования Спринта более подходящей альтернативой будет определение примеров сценариев, которые должны успешно выполняться, и демонстрация прогресса с использованием тестов на основе этих примеров во время Обзора Спринта.

Рекомендуем к прочтению

  • Specification by Example Гойко Аджича. Эта книга охватывает несколько тематических исследований о “Требованиях на Примерах”. Гойко придумал сам термин, чтобы заменить все предыдущие, такие как A-TDD.
  • Bridging the Communication Gap Гойко Аджича. Вышла до “Specification by Example”, фокусируется на прояснении требований и проведении совместных сессий.
  • Acceptance Test Driven Development: An Overview Элизабет Хендриксон. Заметка в блоге и соответствующая статья предлагают обзор A-TDD на подробных примерах использования Robot Framework.
  • Fit for Developing Software Рика Магриджа и Уорда Каннингема. В этой книге большое внимание уделяется улучшению информативности требований посредством Fit таблиц.
  • Robot Framework User Guide. Не покрывает тему A-TDD, но позволяет отлично познакомиться с инструментом Robot Framework.
  • Test-Driven .NET Development with FitNesse Гойко Аджича. В этой книге меньше внимания уделяется A-TDD, а больше - FitNesse. Но в ней проделана хорошая работа по описанию данного инструмента.

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.