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