Уточнение на примере - Specification by example

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
инструменты
Стандарты и свод знаний
Глоссарии
Контуры

Уточнение на примере (SBE) - это совместный подход к определению требования и ориентированный на бизнес функциональные тесты для программных продуктов на основе сбора и иллюстрации требований с использованием реалистичных примеров вместо абстрактных утверждений. Применяется в контексте гибкая разработка программного обеспечения методы, в частности поведенческая разработка. Этот подход особенно эффективен для управления требованиями и функциональными тестами в крупномасштабных проектах значительной предметной и организационной сложности.[1]

Спецификация на примере также известна как разработка на основе примеров, исполняемые требования, разработка через приемочные испытания (ATDD[2] или A-TDD[3]), Agile приемочное тестирование,[4] Тестовые требования (TDR).

Преимущества

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

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

Примеры как единый источник истины

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

Применительно к необходимым изменениям уточненный набор примеров фактически является спецификацией и бизнес-ориентированным тест на прием функциональности программного обеспечения. После внедрения изменения спецификация с примерами становится документом, объясняющим существующие функции. Поскольку проверка таких документов автоматизирована, когда они проверяются часто, такие документы являются надежным источником информации о бизнес-функциях базового программного обеспечения. Чтобы отличить такие документы от типовой печатной документации, которая быстро устаревает,[4] Полный набор спецификаций с примерами называется «Живая документация».[1]

Ключевые практики

Команды, применяющие Спецификацию на примере, обычно успешно применяют следующие шаблоны процессов:[1]

  • Получение объема от целей
  • Совместная разработка - посредством семинаров по спецификациям для всех команд, небольших встреч или обзоров телеконференций
  • Иллюстрирование требований на примерах
  • Спецификации переработки
  • Автоматизация тестов на примерах
  • Частая проверка основного программного обеспечения с помощью тестов
  • Развитие системы документации на основе спецификаций с примерами для поддержки будущего развития

Команды разработчиков программного обеспечения, которые применяют спецификацию на примере в рамках Scrum-фреймворка, обычно тратят 5% -10% своего времени на уточнение бэклога продукта, в том числе на совместное определение, иллюстрирование требований с помощью примеров и уточнение примеров.[3]

Применимость

Спецификация на примере применима к проектам с достаточной организационной сложностью и сложностью предметной области, чтобы вызвать проблемы в понимании или передаче требований с точки зрения предметной области. Это не относится к чисто техническим проблемам или когда основная сложность заключается не в понимании или передаче знаний. Существует документальное подтверждение использования этого подхода в таких областях, как инвестиционный банкинг, финансовая торговля, страхование, бронирование авиабилетов, онлайн-игры и сравнение цен.[1] Аналогичный подход задокументирован также в проекте моделирования атомной электростанции.[3]

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

История

Самым первым задокументированным использованием реалистичных примеров в качестве единого источника истины, требований и автоматизированных тестов в проектах программного обеспечения является проект WyCash +, описанный Уорд Каннингем в статье A Pattern Language of Competitive Development [6][7] в 1996 году. Название «Спецификация на примере» было придумано Мартин Фаулер в 2004 г.[8]

Спецификация на примере - это эволюция клиентского тестирования[9] практика Экстремальное программирование предложено около 1997 года и повсеместного языка[10] идея из Домен-ориентированный дизайн с 2004 года, используя идею тестов черного ящика в качестве требований, описанных Вайнбергом и Гаузе[11] в 1989 г.


Производные работы

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

Сопоставление примеров - это простой метод, с помощью которого можно направить обсуждение и вывести критерии приемлемости в течение 30 минут. Процесс включает разбиение каждой истории на правила и примеры и документирование в форме спецификации с примерами. Пример сопоставления был впервые представлен Мэттом Винном на конференции Agile Alliance в 2015 году и является одним из широко используемых методов в мире BDD.

SHEQC уход

Подобно "Пример сопоставления" SHEQC [12] Уход позволяет командам обрабатывать сложную пользовательскую историю менее чем за 30–45 минут, используя концепцию, называемую непрерывным уходом, с использованием методов дизайн-мышления. SHEQC использует Спецификацию на примерах в качестве стандарта для документирования сценариев. В процессе задействован двойной ромб[13] Правило для мозгового штурма, и результат - это набор вопросов и критериев принятия, снова задокументированных в форме Спецификации с примером для истории. Технология SHEQC впервые была представлена ​​на конференции «Инновации в программной инженерии» ISEC2019, WESSEE. [14] Ранджита Тараила и позже опубликовано на конференции XP2019 как один из основных методов непрерывного ухода за телом. [15]

Автоматизация

Успешное применение Спецификации на примере в крупномасштабных проектах требует частой проверки функциональности программного обеспечения на большом наборе примеров (тестов). На практике это требует автоматизации тестов на примерах. Распространенный подход - автоматизировать тесты, но хранить примеры в форме, удобочитаемой и доступной для нетехнических и технических членов команды, сохраняя примеры как единый источник истины. Этот процесс поддерживается классом инструментов автоматизации тестирования, которые работают с тестами, разделенными на два аспекта - спецификацию и уровень автоматизации. Спецификация теста, которая часто представлена ​​в виде обычного текста или HTML и содержит примеры и вспомогательные описания. Уровень автоматизации подключает пример к тестируемой программной системе. Примеры таких инструментов:

использованная литература

  1. ^ а б c d е Аджич, Гойко (2011). Уточнение на примере: как успешные команды создают правильное программное обеспечение. Мэннинг. ISBN  9781617290084.
  2. ^ Пью, Кен (2011). Разработка, управляемая приемочными тестами Lean-Agile: лучшее программное обеспечение благодаря совместной работе: история разработки, основанной на Lean-Agile приемочных тестах. Эддисон Уэсли. ISBN  978-0-321-71408-4.
  3. ^ а б c Ларман, Крейг; Водде, Бас (2010). Практики масштабирования бережливой и гибкой разработки: крупномасштабная, многоузловая и оффшорная разработка продуктов с крупномасштабным масштабом. Пирсон. ISBN  978-0-321-63640-9.
  4. ^ а б Аджич, Гойко (2009). Устранение разрыва в коммуникации: спецификация на примере и адаптивное приемочное тестирование. Neuri. ISBN  0-9556836-1-0.
  5. ^ Криспин, Лиза; Грегори, Джанет (2008). Гибкое тестирование: практическое руководство для тестировщиков и гибких команд. Эддисон Уэсли. ISBN  978-0-321-53446-0.
  6. ^ Шаблонные языки разработки программ 2. Эддисон-Уэсли. 1996 г. ISBN  978-0-201-89527-8.
  7. ^ Уорд Каннингем. «ЭПИЗОДЫ: образец языка конкурентного развития, часть I». C2.com. Получено 2014-01-08.
  8. ^ Мартин Фаулер 18 марта 2004 (2004-03-18). "SpecificationByExample". Martinfowler.com. Получено 2014-01-08.
  9. ^ Бек, К. (1999). Объяснение экстремального программирования: примите изменения. Эддисон-Уэсли. ISBN  978-0-321-27865-4.
  10. ^ Эванс, Эрик (2004). Доменно-ориентированный дизайн: преодоление сложности в самой основе программного обеспечения. Эддисон-Уэсли. ISBN  0-321-12521-5.
  11. ^ Вайнберг, Джеральд; Гаузе, Дональд (1989). Изучение требований: качество перед дизайном. Дорсет-Хаус. ISBN  0-932633-13-7.
  12. ^ Тараил, Ранджит (09.02.2019). "SHE QC A story grooming method". confengine.com. Получено 2019-06-06.
  13. ^ «Двойной алмаз: стратегия + выполнение верного решения». ThoughtWorks. 2015-02-03. Получено 2019-06-06.
  14. ^ Тараил, Ранджит. «ISEC2019: WESEE 2019». sites.google.com. Получено 2019-06-06.
  15. ^ Тараил, Ранджит. "XP2019 SHEQC". xp2019.sched.com. Получено 2019-06-06.

внешние ссылки