예시별 사양

Specification by example
다음에 대한 시리즈 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
연습
도구들
지식의 표준 및 본문
용어집
윤곽선

사례별 규격(SBE)은 추상적인 진술 대신 현실적인 예를 사용하여 요구사항을 포착하고 설명함으로써 소프트웨어 제품에 대한 요구사항을 정의하고 비즈니스 지향적인 기능 테스트를 정의하기 위한 공동의 접근방식이다. 민첩한 소프트웨어 개발 방법, 특히 행동 주도형 개발의 맥락에서 적용한다. 이 접근방식은 특히 중요한 영역과 조직적 복잡성이 있는 대규모 프로젝트에 대한 요구사항과 기능 테스트를 관리하는데 성공적이다.[1]

예에 따른 사양은 예시 중심 개발, 실행 가능한 요구사항, 합격 테스트 기반 개발(ATDD[2] 또는 A-TDD[3]), 신속한 변화를 위한 인수 테스트,[4] 테스트 기반 요구사항(TDR)이라고도 한다.

이점

매우 추상적이거나 참신한 새로운 개념은 구체적인 예시 없이는 이해하기 어려울 수 있다.[citation needed] 사례별 사양은 정확한 이해를 구하고자 하며, 소프트웨어 개발의 피드백 루프를 현저히 감소시켜 재작업을 줄이고, 제품 품질을 높이며, 소프트웨어 변경에 대한 처리 시간을 단축하고, 테스터, 분석가 및 소프트웨어 개발에 관련된 다양한 역할의 활동을 보다 효과적으로 조정하도록 한다. 개발자[1]

하나의 진리의 출처로서의 예

사례별 명세서의 주요 측면은 모든 관점에서 요구되는 변경에 대한 하나의 진실성 출처를 만드는 것이다. 비즈니스 분석가가 자체 문서를 작성하고, 소프트웨어 개발자는 자체 문서를 유지관리하며, 테스터는 별도의 기능 테스트 세트를 유지관리할 때, 소프트웨어 전송 효율성은 그러한 다른 버전의 진실들을 지속적으로 조정하고 동기화할 필요성에 의해 크게 감소한다. 짧은 반복 주기와 함께, 그러한 조정은 종종 주간 또는 격주 단위로 요구된다. 사양서를 예로 들면, 모든 사람의 이해를 사로잡는 하나의 진리의 원천을 만드는 데 서로 다른 역할이 참여한다. 예를 들어, 명료성과 정밀도를 제공함으로써 동일한 정보를 규격과 비즈니스 지향 기능 시험으로 모두 사용할 수 있다. 기능적 공백의 명확화, 누락 또는 불완전한 요건 또는 추가 시험과 같이 개발 또는 전달 중에 발견된 모든 추가 정보는 이 단일 진실에 추가된다. 기능성에 대한 진실의 출처는 하나뿐이기 때문에 전달 주기 내 지식의 조정, 번역, 해석은 필요 없다.

요구되는 변경에 적용할 때, 세분화된 예시 집합은 소프트웨어 기능성의 수용을 위한 명세서 및 비즈니스 지향 시험이다. 변경이 실행된 후, 예를 갖춘 명세서는 기존의 기능성을 설명하는 문서가 된다. 이러한 문서의 검증이 자동화되므로, 자주 검증될 때 이러한 문서는 기본 소프트웨어의 비즈니스 기능에 대한 신뢰할 수 있는 정보 출처가 된다. 이러한 문서와 인쇄된 일반적인 문서를 구별하기 위해, 이러한 문서와 인쇄된 문서를 구별하기 위해,[4] 예를 들어 전체 사양을 리빙 문서화라고 한다.[1]

주요 작업 방식

사례별 사양을 적용하는 팀은 일반적으로 다음과 같은 프로세스 패턴을 성공적으로 적용한다.[1]

  • 목표에서 범위 도출
  • 모든 팀 사양 워크샵, 소규모 회의 또는 원격 회의 검토를 통해 협업적으로 지정
  • 예를 사용하여 요구 사항 설명
  • 정제사양서
  • 예제를 기반으로 테스트 자동화
  • 테스트를 사용하여 기본 소프트웨어 자주 확인
  • 사양에서 예시까지 문서 시스템을 발전시켜 향후 개발 지원

Scrum 프레임워크 내에서 사례별로 사양을 적용하는 소프트웨어 팀은 일반적으로 제품 백로그를 수정하는 데 5%-10%의 시간을 소비하는데 여기에는 협업적으로 사양을 지정하고 예를 사용하여 요구사항을 설명하며 사례를 수정하는 것이 포함된다.[3]

매핑 예제

예제 매핑은 대화를 주도하고 단시간에 수락 기준을 도출할 수 있는 간단한 기술이다. 이 과정은 이야기를 사례별로 명세서의 형태로 문서화된 규칙과 사례로 나누며, BDD 영역에서 널리 사용되는 기술이다.[5]

적용가능성

사례별 규격은 사업영역의 관점에서 요구사항을 이해하거나 전달하는 데 있어 문제를 야기할 수 있는 조직적 및 영역적 복잡성이 충분한 프로젝트에 적용된다. 이는 순수하게 기술적인 문제나 핵심 복잡성이 지식을 이해하거나 전달하는 데 있지 않은 경우에는 적용되지 않는다. 투자 은행, 금융 거래, 보험, 항공권 예약, 온라인 게임 및 가격 비교를 포함한 도메인에서 이 접근방식에 대한 문서화된 사용법이 있다.[1] 유사한 접근방식은 원자력 발전소 시뮬레이션 프로젝트에서도 문서화된다.[3]

공유된 예에 기반한 테스트는 비즈니스 관점에서 소프트웨어를 제공하면서 팀을 지원하도록 설계된 테스트 범주에 가장 적합하며(Accessible Testing Quadants[6] 참조) 적절한 제품이 구축되도록 보장한다. 그들은 소프트웨어 시스템을 순수한 기술적 관점(단위 시험, 구성요소 또는 기술 통합 시험과 같이 제품이 올바른 방식으로 구축되었는지 평가하는 시험)이나 제품이 개발된 후 제품을 평가하는 시험(보안 침투 시험 등)을 대체하지 않는다.

역사

소프트웨어 프로젝트에서 단일 진리, 요건 및 자동화된 시험의 출처로서 현실적인 사례를 가장 일찍 문서화한 것은 1996년 Ward Cunningham이 논문 A Patternal Language of Competitive Development에서 설명한 WyCash+ 프로젝트다. 예에 의한 이름 명세서는 2004년에 마틴 파울러에 의해 만들어졌다.[9]

사례별 명세서는 1997년경 제안된 익스트림 프로그래밍의 고객 테스트[10] 관행과 2004년부터 도메인 주도 설계의 유비쿼터스 언어[11] 아이디어를 발전시킨 것으로, 1989년 와인버그와 가스가[12] 기술한 요구사항으로 블랙박스 테스트 개념을 사용했다.

자동화

대규모 프로젝트에서 사례별 사양을 성공적으로 적용하려면 대규모 예제(테스트)에 대한 소프트웨어 기능의 빈번한 검증이 필요하다. 실제로 이를 위해서는 예를 바탕으로 한 시험을 자동화해야 한다. 일반적인 접근방식은 시험을 자동화하는 것이지만 예시를 비기술 및 기술 팀원이 읽을 수 있고 접근할 수 있는 형태로 유지하는 것이며, 예시를 하나의 진실로 유지하는 것이다. 이 프로세스는 두 가지 측면, 즉 규격과 자동화 계층으로 나뉜 테스트로 작동하는 테스트 자동화 툴의 클래스에 의해 지원된다. 종종 일반 텍스트 또는 HTML 형식으로 되어 있고 예시와 보조 설명을 포함하는 테스트의 사양. 자동화 계층은 예를 테스트 중인 소프트웨어 시스템에 연결한다. 그러한 도구의 예는 다음과 같다.

참조

  1. ^ a b c d e Adzic, Gojko (2011). Specification by example: How successful teams deliver the right software. Manning. ISBN 9781617290084.
  2. ^ Pugh, Ken (2011). Lean-Agile Acceptance Test Driven Development: Better Software Through Collaboration: A Tale of Lean-Agile Acceptance Test Driven Development. Addison Wesley. ISBN 978-0-321-71408-4.
  3. ^ a b c Larman, Craig; Vodde, Bas (2010). Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Pearson. ISBN 978-0-321-63640-9.
  4. ^ a b Adzic, Gojko (2009). Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri. ISBN 0-9556836-1-0.
  5. ^ Wynne, Matt (8 December 2015). "Introducing Example Mapping". Cucumber Blog. Retrieved 10 May 2021.
  6. ^ Crispin, Lisa; Gregory, Janet (2008). Agile Testing: A Practical Guide for Testers and Agile Teams. Addison Wesley. ISBN 978-0-321-53446-0.
  7. ^ Pattern Languages of Program Design 2. Addison-Wesley. 1996. ISBN 978-0-201-89527-8.
  8. ^ Ward Cunningham. "EPISODES: A Pattern Language of Competitive Development Part I". C2.com. Retrieved 2014-01-08.
  9. ^ Martin Fowler 18 March 2004 (2004-03-18). "SpecificationByExample". Martinfowler.com. Retrieved 2014-01-08.
  10. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 978-0-321-27865-4.
  11. ^ Evans, Eric (2004). Domain-Driven Design:Tackling Complexity in the Heart of Software. Addison-Wesley. ISBN 0-321-12521-5.
  12. ^ Weinberg, Gerald; Gause, Donald (1989). Exploring Requirements: Quality Before Design. Dorset House. ISBN 0-932633-13-7.

외부 링크