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

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

Требования на Примерах (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? Иллюстрация ниже даёт общее представление.

Обзор A-TDD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вступление — Владелец Продукта приветствует всех в начале сессии и объясняет его цель.
Отбор — команда и Владелец Продукта выбирают элементы из Бэклога продукта, над которыми будут работать.
Обзор — Владелец Продукта или его представитель дают короткий обзор выбранных требований.
Разделение — команда делится на две или три подгруппы, каждая из которых берёт один элемент и начинает набрасывать примеры на досках. Владелец Продукта и его представители перемещаются между подгруппами.
Слияние — подгруппы сходятся на время, чтобы поделиться результатами с остальными.
Повторение — цикл разделение-слияние обычно занимает 30-45 минут. Одна сессия содержит несколько циклов.
Заключение — Владелец Продукта подводит итоги работы. Далее следует краткая рефлексия самой сессии.
Фиксация результатов — участники делают фотографии всех записей и размещают их в вики. Они уже могут сделать выжимку в виде нескольких тестов и оформить их в своём 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, как и Скрам, содержит цикл инспекции-адаптации, когда результаты доставляются заинтересованным лицам, которые инспектируют итоги, используя тесты, и принимают решения, как действовать дальше - какие требования реализовать следующими.

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

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

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

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