Спецификация на примере
| Часть серии о |
| Разработка программного обеспечения |
|---|
Спецификация на примере ( SBE ) — это совместный подход к определению требований и бизнес-ориентированных функциональных тестов для программных продуктов, основанный на сборе и иллюстрации требований с использованием реалистичных примеров вместо абстрактных утверждений. Он применяется в контексте гибких методов разработки программного обеспечения, в частности разработки, основанной на поведении . Этот подход особенно эффективен для управления требованиями и функциональными тестами в крупномасштабных проектах значительной предметной и организационной сложности. [1]
Спецификация на основе примеров также известна как разработка на основе примеров, исполняемые требования, разработка на основе приемочных испытаний (ATDD). [2] или A-TDD [3] ), Agile приемочное тестирование, [4] Требования, основанные на тестировании (TDR).
Преимущества [ править ]
Очень абстрактные или новые новые концепции может быть трудно понять без конкретных примеров. [ нужна ссылка ] Спецификация на примере предназначена для формирования точного понимания и значительно сокращает циклы обратной связи при разработке программного обеспечения, что приводит к меньшему количеству переделок, более высокому качеству продукта, более быстрому времени внесения изменений в программное обеспечение и лучшему согласованию действий различных ролей, участвующих в разработке программного обеспечения, таких как тестировщики. , аналитики и разработчики. [1]
как единственный Примеры истины источник
Ключевым аспектом спецификации на примере является создание единого источника истины о необходимых изменениях со всех точек зрения. Когда бизнес-аналитики работают над собственными документами, разработчики программного обеспечения ведут собственную документацию, а тестировщики — отдельный набор функциональных тестов, эффективность доставки программного обеспечения значительно снижается из-за необходимости постоянно координировать и синхронизировать эти разные версии истины. При коротких итеративных циклах такая координация часто требуется еженедельно или раз в две недели. При использовании «Спецификации на примере» разные роли участвуют в создании единого источника истины, который будет понятен каждому. Примеры используются для обеспечения ясности и точности, чтобы одну и ту же информацию можно было использовать как в качестве спецификации , так и в качестве бизнес-ориентированного функционального теста. Любая дополнительная информация, обнаруженная во время разработки или поставки, такая как уточнение функциональных пробелов, отсутствующие или неполные требования или дополнительные тесты, добавляется к этому единому источнику истины. Поскольку существует только один источник достоверной информации о функциональности, нет необходимости в координации, переводе и интерпретации знаний внутри цикла поставки.
Применительно к необходимым изменениям уточненный набор примеров фактически представляет собой спецификацию и бизнес-ориентированный тест на приемку функциональности программного обеспечения. После реализации изменения спецификация с примерами становится документом, объясняющим существующий функционал. Поскольку проверка таких документов автоматизирована, при частой проверке такие документы являются надежным источником информации о бизнес-функциональности базового программного обеспечения. Чтобы отличить такие документы от типичной печатной документации, которая быстро устаревает, [4] полный набор спецификаций с примерами называется «Живая документация». [1]
Ключевые практики [ править ]
Команды, успешно применяющие спецификацию на примере, обычно применяют следующие шаблоны процессов: [1]
- Получение масштаба из целей
- Совместное определение спецификаций — посредством групповых семинаров по спецификациям, небольших встреч или обзоров на телеконференциях.
- Иллюстрирование требований примерами
- Спецификации переработки
- Автоматизация тестов на примерах
- Проверка базового программного обеспечения, частая проверка с помощью тестов.
- Развитие системы документации из спецификаций с примерами для поддержки дальнейшего развития.
Команды разработчиков программного обеспечения, которые применяют спецификации на примерах в рамках Scrum, обычно тратят 5–10% своего времени на доработку журнала невыполненных продуктов, включая совместную спецификацию, иллюстрацию требований с использованием примеров и уточнение примеров. [3]
Пример сопоставления [ править ]
Сопоставление примеров — это простой метод, который может направить разговор и за короткое время вывести критерии приемки. Этот процесс разбивает истории на правила и примеры, документированные в виде спецификации за примером, и является широко используемым методом в сфере BDD. [5]
Применимость [ править ]
Спецификация на примере применяется к проектам с достаточной организационной и предметной сложностью, которая может вызвать проблемы в понимании или передаче требований с точки зрения бизнес-домена. Это не применимо к чисто техническим проблемам или к случаям, когда основная сложность заключается не в понимании или передаче знаний. Задокументировано использование этого подхода в таких областях, как инвестиционно-банковская деятельность, финансовая торговля, страхование, бронирование авиабилетов, онлайн-игры и сравнение цен. [1] Подобный подход задокументирован и в проекте моделирования атомной электростанции. [3]
Тесты, основанные на общих примерах, лучше всего подходят для категории тестов, предназначенных для поддержки команды при доставке программного обеспечения с точки зрения бизнеса (см. Квадранты гибкого тестирования). [6] ) — обеспечение создания правильного продукта. Они не заменяют тесты, которые рассматривают программную систему с чисто технической точки зрения (те, которые оценивают, правильно ли построен продукт, например модульные тесты, тесты компонентов или технической интеграции) или тесты, которые оценивают продукт после его разработки. (например, тесты на проникновение в систему безопасности).
История [ править ]
Самым ранним задокументированным использованием реалистичных примеров в качестве единого источника истины, требований и автоматизированных тестов в проектах программного обеспечения является проект WyCash+, описанный Уордом Каннингемом в статье «Язык шаблонов конкурентной разработки». [7] [8] в 1996 году. Название «Спецификация на примере» было придумано Мартином Фаулером в 2004 году. [9]
Спецификация на примере — это эволюция клиентского тестирования. [10] практика экстремального программирования, предложенная примерно в 1997 году, и Ubiquitous Language [11] идея из доменно-ориентированного проектирования 2004 года с использованием идеи тестов черного ящика в качестве требований, описанных Вайнбергом и Гаузе. [12] в 1989 году.
Автоматизация [ править ]
Успешное применение спецификации на примере крупномасштабных проектов требует частой проверки функциональности программного обеспечения на большом наборе примеров (тестов). На практике это требует автоматизации тестов на примерах. Распространенный подход — автоматизировать тесты, но сохранять примеры в форме, читаемой и доступной для нетехнических и технических членов команды, сохраняя примеры как единый источник истины. Этот процесс поддерживается классом инструментов автоматизации тестирования, которые работают с тестами, разделенными на два аспекта — уровень спецификации и уровень автоматизации. Спецификация теста, которая часто представлена в текстовой или HTML-форме и содержит примеры и вспомогательные описания. Уровень автоматизации соединяет пример с тестируемой программной системой. Примеры таких инструментов:
- Бег
- Конкордеон
- Огурец
- Фитнес
- Структура интегрированного тестирования
- Робот Фреймворк
- SpecFlow для .NET
- Датчик (программное обеспечение)
Ссылки [ править ]
- ^ Перейти обратно: а б с д и Аджич, Гойко (2011). Спецификация на примере: как успешные команды создают правильное программное обеспечение . Мэннинг. ISBN 9781617290084 .
- ^ Пью, Кен (2011). Lean-Agile-разработка на основе приемочных тестов: лучшее программное обеспечение благодаря сотрудничеству: рассказ о Lean-Agile-разработке на основе приемочных тестов . Эддисон Уэсли. ISBN 978-0-321-71408-4 .
- ^ Перейти обратно: а б с Ларман, Крейг; Водде, Бас (2010). Практики масштабирования бережливой и гибкой разработки: разработка крупных, многосайтовых и оффшорных продуктов с помощью крупномасштабного Scrum . Пирсон. ISBN 978-0-321-63640-9 .
- ^ Перейти обратно: а б Аджич, Гойко (2009). Преодоление разрыва в общении: спецификация на примере и гибкое приемочное тестирование . Неури. ISBN 0-9556836-1-0 .
- ^ Винн, Мэтт (8 декабря 2015 г.). «Введение в пример сопоставления» . Огуречный блог . Проверено 10 мая 2021 г.
- ^ Криспин, Лиза ; Грегори, Джанет (2008). Agile-тестирование: Практическое руководство для тестировщиков и Agile-команд . Эддисон Уэсли. ISBN 978-0-321-53446-0 .
- ^ Языки шаблонов проектирования программ 2 . Аддисон-Уэсли. 1996. ISBN 978-0-201-89527-8 .
- ^ Уорд Каннингем. «ЭПИЗОДЫ: Язык шаблонов конкурентного развития, часть I» . C2.com . Проверено 8 января 2014 г.
- ^ Мартин Фаулер, 18 марта 2004 г. (18 марта 2004 г.). «СпецификацияПоПримеру» . Мартинфаулер.com . Проверено 8 января 2014 г.
{{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка ) - ^ Бек, К. (1999). Объяснение экстремального программирования: примите изменения . Аддисон-Уэсли. ISBN 978-0-321-27865-4 .
- ^ Эванс, Эрик (2004). Доменно-ориентированное проектирование: решение проблем, лежащих в основе программного обеспечения . Аддисон-Уэсли. ISBN 0-321-12521-5 .
- ^ Вайнберг, Джеральд ; Гаус, Дональд (1989). Изучение требований: качество прежде проектирования . Дорсет Хаус. ISBN 0-932633-13-7 .