Войти
Спецификация по примеру (SBE ) - это совместный подход к определению требований и бизнес-ориентированные функциональные тесты для программных продуктов, основанные на регистрации и иллюстрации требований с использованием реалистичных примеров вместо абстрактных утверждений. Он применяется в контексте методов гибкой разработки программного обеспечения, в частности разработки, управляемой поведением. Этот подход особенно эффективен для управления требованиями и функциональными тестами в крупномасштабных проектах значительной предметной и организационной сложности.
Спецификация на примере также известна как разработка на основе примеров, исполняемые требования, приемочные испытания– управляемая разработка (ATDD или A-TDD), Agile Acceptance Testing, Test-Driven Requirements (TDR).
Человеческий мозг, как правило, не так хорош в понимании абстракций или новых идей / концепций при первом знакомстве с ними, но они действительно хороши в выводе абстракций или концепций, если приведено достаточно конкретных примеров. Чем больше примеров нам приведено, тем больше вероятность, что мы правильно поймем предполагаемый смысл. Кроме того, используя конкретные примеры, они становятся более знакомыми и связанными с чем-то похожим на наш прошлый опыт, что в целом упрощает их понимание.
Успешное применение спецификации задокументировано для значительного сокращения циклов обратной связи при разработке программного обеспечения, что приводит к меньшему количеству доработок, повышению качества продукта, сокращению времени выполнения изменений программного обеспечения и лучшему согласованию действий различных ролей, участвующих в разработке программного обеспечения. например, тестировщики, аналитики и разработчики.
Ключевым аспектом спецификации на примере является создание единого источника истины о необходимых изменениях со всех точек зрения. Когда бизнес-аналитики работают со своими собственными документами, разработчики программного обеспечения поддерживают свою собственную документацию, а тестировщики поддерживают отдельный набор функциональных тестов, доставка программного обеспечения эффективность значительно снижается на необходимость постоянно координировать и синхронизировать эти разные версии истины. При коротких итерационных циклах такая координация часто требуется еженедельно или раз в две недели. С помощью «Спецификации на примере» разные роли участвуют в создании единого источника истины, который отражает понимание каждого. Примеры используются для обеспечения ясности и точности, поэтому одну и ту же информацию можно использовать как в качестве спецификации, так и в качестве бизнес-ориентированного функционального теста. Любая дополнительная информация, обнаруженная во время разработки или доставки, такая как уточнение функциональных пробелов, отсутствующих или неполных требований или дополнительных тестов, добавляется к этому единственному источнику правды. Поскольку существует только один источник правды о функциональности, нет необходимости в координации, переводе и интерпретации знаний внутри цикла доставки.
Применительно к требуемым изменениям уточненный набор примеров фактически является спецификацией и бизнес-ориентированным тестом на приемлемость функциональности программного обеспечения. После внесения изменения спецификация с примерами становится документом, объясняющим существующие функции. Поскольку проверка таких документов автоматизирована, когда они проверяются часто, такие документы являются надежным источником информации о бизнес-функциях базового программного обеспечения. Чтобы отличить такие документы от типичной печатной документации, которая быстро устаревает, полный набор спецификаций с примерами называется Живой документацией.
Команды, применяющие Спецификацию на примерах, обычно успешно применяют следующие шаблоны процессов:
Группы разработчиков программного обеспечения, которые применять спецификацию на примере в рамках Scrum, как правило, тратят 5% -10% своего времени на уточнение бэклога продукта, включая совместное определение, иллюстрирование требований с помощью примеров и уточнение exa mples.
Спецификация на примере применима к проектам с достаточной организационной и предметной сложностью, чтобы вызвать проблемы в понимании или передаче требований с точки зрения бизнес-домена. Это не относится к чисто техническим проблемам или когда основная сложность заключается не в понимании или передаче знаний. Есть документально подтвержденные примеры использования этого подхода в таких областях, как инвестиционный банкинг, финансовая торговля, страхование, бронирование авиабилетов, онлайн-игры и сравнение цен. Аналогичный подход задокументирован также в проекте моделирования атомной электростанции.
Тесты, основанные на общих примерах, лучше всего подходят для категории тестов, предназначенных для поддержки команды при доставке программного обеспечения с точки зрения бизнеса (см. Квадранты Agile Testing.) - обеспечение создания правильного продукта. Они не заменяют тесты, которые рассматривают программную систему с чисто технической точки зрения (те, которые оценивают, правильно ли построен продукт, например, модульные тесты, тесты компонентов или технической интеграции), или тесты, оценивающие продукт после его разработки. (например, тесты на проникновение в систему безопасности).
Самым ранним задокументированным использованием реальных примеров в качестве единого источника истины, требований и автоматизированных тестов в проектах программного обеспечения является проект WyCash +, описанный Уордом Каннингемом в статье «Язык шаблонов конкурентного развития» в 1996 году. Название «Спецификация на примере» было придумано Мартином Фаулером в 2004 году.
Спецификация на примере - это эволюция практики клиентского тестирования Экстремальное программирование было предложено примерно в 1997 году, а идея универсального языка - из Доменно-ориентированный дизайн - из 2004 года, используя идею тестов черного ящика в качестве требований, описанных Вайнбергом и Гаузе в 1989 году.
.
Пример сопоставления - это простой метод, который может направить разговор и вывести критерии приемлемости в течение 30 минут. Процесс включает разбиение каждой истории на правила и примеры и документирование в виде Уточнение на примерах. Пример сопоставления был впервые представлен Мэттом Винном на конференции Agile-альянсов 2015 года и является одним из широко используемых методов в мире BDD.
Подобно «Пример сопоставления» Обработка SHEQC позволяет командам подготовить сложную пользовательскую историю менее чем за 30–45 минут, используя концепцию, называемую непрерывной очисткой, с использованием методов дизайнерского мышления. SHEQC использует Спецификацию на примерах в качестве стандарта для документирования сценариев. Этот процесс включает в себя правило двойного ромба для мозгового штурма, и результатом является набор вопросов и критериев принятия, снова задокументированных в форме Спецификации с примером для истории. Уход SHEQC был впервые представлен на конференции «Инновации в разработке программного обеспечения» ISEC2019, WESSEE Ранджит Тарайил, а затем опубликован на конференции XP2019 как один из основных методов непрерывного ухода
Успешное применение спецификации Например, в крупномасштабных проектах требуется частая проверка функциональности программного обеспечения на большом наборе примеров (тестов). На практике это требует автоматизации тестов на примерах. Распространенный подход - автоматизировать тесты, но сохранять примеры в форме, удобочитаемой и доступной для нетехнических и технических членов команды, сохраняя примеры как единый источник истины. Этот процесс поддерживается классом инструментов автоматизации тестирования, которые работают с тестами, разделенными на два аспекта - спецификацию и уровень автоматизации. Спецификация теста, которая часто представлена в виде обычного текста или HTML и содержит примеры и вспомогательные описания. Уровень автоматизации подключает пример к тестируемой программной системе. Примеры таких инструментов:
