BDD-예제 별 사양

'Specification by Example'의 저자 인 Gojko Adzic에 따르면, Specification by Example은 소프트웨어 제품의 변경을 촉진하여 올바른 제품이 효율적으로 제공되도록하는 일련의 프로세스 패턴입니다.”

예제 별 사양은 추상적 인 설명 대신 현실적인 예제를 사용하여 요구 사항을 캡처하고 설명하는 것을 기반으로 소프트웨어 제품에 대한 요구 사항 및 비즈니스 지향 기능 테스트를 정의하는 공동 접근 방식입니다.

예제 별 사양 – 개요

예제 별 사양의 목표는 우선 순위가 지정되고 검증 가능한 비즈니스 요구 사항의 개발 및 제공에 초점을 맞추는 것입니다. 예에 의한 사양의 개념 자체는 비교적 새로운 것이지만 기존 관행을 단순히 재구성 한 것입니다.

유비쿼터스 언어로 알려진 매우 구체적이고 간결한 어휘를 지원합니다.

실행 가능한 요구 사항을 활성화합니다.
팀의 모든 사람이 사용합니다.
교차 기능 팀이 만듭니다.
모든 사람의 이해를 포착합니다.

예제 별 사양은 비즈니스 도메인을 반영하는 자동화 된 테스트를 구축하기위한 직접적인 입력으로 사용할 수 있습니다. 따라서 예제 별 사양의 초점은 올바른 제품을 구축하고 제품을 올바르게 구축하는 데 있습니다.

예제 별 사양 목적

예제 별 사양의 주요 목표는 올바른 제품을 만드는 것입니다. 그것은 공유 된 이해에 초점을 맞추고, 따라서 단일 진실의 근원을 확립합니다. 허용 기준을 자동화하여 결함 감지가 아닌 결함 예방에 초점을 맞 춥니 다. 또한 결함을 조기에 발견하기 위해 조기에 테스트를 진행합니다.

SbE 사용

예제 별 사양은 비즈니스 가치를 설명하는 예상 시스템 동작을 설명하는 데 사용됩니다. 이 그림은 구체적이고 실제적인 예입니다. 이 예제는 다음과 같은 실행 가능한 요구 사항을 만드는 데 사용됩니다.

번역없이 테스트 할 수 있습니다.
라이브 문서에 캡처되었습니다.

다음은 특정 사양을 설명하기 위해 예제를 사용하는 이유입니다.

이해하기 더 쉽습니다.
오해하기가 더 어렵습니다.

SbE의 장점

예제에 의한 사양 사용의 장점은 다음과 같습니다.

품질 향상
낭비 감소
생산 결함 위험 감소
집중된 노력
보다 안전하게 변경할 수 있습니다.
비즈니스 참여 향상

SbE의 응용

예에 의한 사양-

복잡한 비즈니스 또는 복잡한 조직.
순전히 기술적 인 문제에 대해서는 잘 작동하지 않습니다.
UI 중심 소프트웨어 제품에서는 잘 작동하지 않습니다.
레거시 시스템에도 적용 할 수 있습니다.

SbE 및 수락 테스트

수락 테스트 측면에서 예제 별 사양의 장점은 다음과 같습니다.

세부 요구 사항 및 테스트에 하나의 그림이 사용됩니다.
프로젝트의 진행은 수락 테스트 측면에서-
- 각 테스트는 동작을 테스트하는 것입니다.
- 테스트는 동작에 대해 통과하거나 통과하지 않습니다.
- 통과 테스트는 특정 동작이 완료되었음을 나타냅니다.
- 100 개의 행동을 완료해야하는 프로젝트가 60 개의 행동을 완료하면 60 %가 완료된 것입니다.
테스터는 결함 수정에서 결함 방지로 전환하고 솔루션 설계에 기여합니다.
자동화를 통해 요구 사항 변경이 솔루션에 미치는 영향을 즉시 이해할 수 있습니다.

예제 별 사양 – 다른 역할에 대한 의미

사례 별 사양의 목표는 비즈니스 가치를 제공하기 위해 프로젝트 전반에 걸쳐 고객을 포함하여 팀의 모든 사람의 협업을 촉진하는 것입니다. 더 나은 이해를 위해 모든 사람이 동일한 어휘를 사용합니다.

역할	SbE 사용
비즈니스 분석가	요구 사항은 명확하고 기능적 차이가 없습니다. 개발자는 실제로 사양을 읽습니다.
개발자	개발자는 개발중인 내용을 더 잘 이해합니다. 올바르게 개발 된 사양을 세어 개발 진행 상황을 더 잘 추적합니다.
시험 장치	테스터는 테스트 대상을 더 잘 이해합니다. 테스터는 처음부터 참여하고 설계에서 역할을합니다. 테스터는 결함 감지보다는 결함 예방을 위해 노력합니다.
여러분	처음부터 오류를 식별하여 시간을 절약합니다. 처음부터 양질의 제품이 생산됩니다.

SbE – 일련의 프로세스 패턴

이 장의 시작 부분에서 살펴본 것처럼 예제 별 사양은 올바른 제품이 효율적으로 제공되도록 소프트웨어 제품의 변경을 용이하게하는 일련의 프로세스 패턴으로 정의됩니다.

프로세스 패턴은-

협업 사양
예제를 사용하여 사양 설명
사양 수정
자동화 예제
자주 확인
살아있는 문서

협업 사양

협업 사양의 목표는 다음과 같습니다.

공통된 이해와 공유 된 어휘를 갖기 위해 팀에서 다양한 역할을 얻으십시오.
모든 사람이 프로젝트에 참여하도록하여 기능에 대한 서로 다른 관점을 제공 할 수 있도록합니다.
기능의 공유 및 소유권을 보장합니다.

이러한 목표는 Three Amigos 회의라고도하는 사양 워크숍에서 충족됩니다. Three Amigos는 BA, QA 및 개발자입니다. 프로젝트에 다른 역할이 있지만이 세 가지 역할은 정의부터 기능 제공까지 책임이 있습니다.

During the meeting −

비즈니스 분석가 (BA)는 새로운 기능에 대한 요구 사항과 테스트를 제시합니다.
세 명의 Amigos (BA, Developer 및 QA)는 새로운 기능에 대해 논의하고 사양을 검토합니다.
QA와 개발자는 누락 된 요구 사항도 식별합니다.
세 명의 아미고
- 유비쿼터스 언어를 사용하여 공유 모델을 활용합니다.
- 도메인 어휘를 사용합니다 (필요한 경우 용어집이 유지됨).
- 차이점과 갈등을 찾으십시오.
이 시점에서 구현 세부 사항으로 이동하지 마십시오.
기능이 충분히 지정되었는지에 대한 합의에 도달하십시오.
요구 사항과 테스트 소유권을 공유하여 품질 사양을 용이하게합니다.
요구 사항은 명시적이고 명확한 요구 사항을 제공하는 시나리오로 제공됩니다. 시나리오는 사용자 관점에서 시스템 동작의 예입니다.

예제를 사용하여 사양 설명

시나리오는 Given-When-Then 구조를 사용하여 지정되어 테스트 가능한 사양을 생성합니다.

Given <일부 전제 조건>

And <추가 전제 조건> Optional

When <동작 / 트리거 발생>

Then <일부 포스트 조건>

And <추가 포스트 조건> Optional

이 사양은 시스템 동작의 예입니다. 또한 시스템의 수락 기준을 나타냅니다.

팀은 예제를 논의하고 예제가 기능의 예상되는 동작을 포함한다는 동의가있을 때까지 피드백을 통합합니다. 이것은 좋은 테스트 범위를 보장합니다.

사양 수정

사양을 구체화하려면

예제를 정확하게 작성하십시오. 예제가 복잡해지면 더 간단한 예제로 분할하십시오.
비즈니스 관점에 초점을 맞추고 기술적 세부 사항을 피하십시오.
긍정적이고 부정적인 조건을 모두 고려하십시오.
도메인 별 어휘를 준수하십시오.
고객과 사례를 논의하십시오.
- 이를 위해 대화를 선택하십시오.
- 고객이 관심있는 예제 만 고려하십시오. 이렇게하면 필요한 코드 만 생성 할 수 있으며 필요하지 않을 수있는 모든 가능한 조합을 포함하지 않습니다.
시나리오가 통과하는지 확인하려면 해당 시나리오의 모든 테스트 사례가 통과해야합니다. 따라서 테스트 가능하도록 사양을 개선하십시오. 테스트 케이스에는 다양한 범위 및 데이터 값 (경계 및 코너 케이스)은 물론 데이터 변경을 초래하는 다양한 비즈니스 규칙이 포함될 수 있습니다.
복잡한 계산, 데이터 조작 / 변환 등과 같은 추가 비즈니스 규칙을 지정합니다.
비 기능적 시나리오 (예 : 성능,로드, 유용성 등)를 예제 별 사양으로 포함

자동화 예제

자동화 계층은 매우 단순하게 유지되어야합니다. 테스트중인 시스템에 사양을 배선하기 만하면됩니다. 같은 도구를 사용할 수 있습니다.

DSL (Domain Specific Language)을 사용하여 테스트 자동화를 수행하고 입력과 출력 간의 명확한 연결을 보여줍니다. 스크립트가 아닌 사양에 중점을 둡니다. 테스트가 정확하고 이해하기 쉬우 며 테스트 가능한지 확인하십시오.

자주 검증

모든 변경 (추가 / 수정)과 함께 개발 파이프 라인에 예제 유효성 검사를 포함합니다. 제품의 품질을 보장하기 위해 채택 할 수있는 (그리고 채택해야하는) 많은 기술과 도구가 있습니다. 세 가지 주요 원칙을 중심으로합니다.Test Early, Test Well 과 Test Often.

취약한 링크를 식별 할 수 있도록 자주 테스트를 실행하십시오. 동작을 나타내는 예제는 진행 상황을 추적하는 데 도움이되며 동작은 해당 테스트를 통과 한 후에 만 완료된다고합니다.

살아있는 문서

사양은 가능한 한 간단하고 짧게 유지하십시오. 사양을 구성하고 작업이 진행됨에 따라 발전시킵니다. 팀의 모든 사람이 문서에 액세스 할 수 있도록합니다.

예제 프로세스 단계에 의한 사양

그림은 예제 별 사양의 프로세스 단계를 보여줍니다.

안티 패턴

안티 패턴은 나쁜 프로그래밍 관행으로 간주되는 소프트웨어 개발의 특정 패턴입니다. 공식화되고 일반적으로 좋은 개발 관행으로 간주되는 일반적인 문제에 대한 일반적인 접근 방식 인 디자인 패턴과 달리, 안티 패턴은 반대이며 바람직하지 않습니다.

안티 패턴은 다양한 문제를 일으 킵니다.

안티 패턴	문제점
협업 없음	많은 가정 잘못된 것을 구축 잘못된 것을 테스트 코드가 완료되면 인식하지 못함
코드가 완료되면 인식하지 못함	테스트 유지하기 어려움 이해하기 어려운 사양 비즈니스 담당자의 관심 상실
너무 상세하거나 UI 중심적인 예	테스트 유지하기 어려움 이해하기 어려운 사양 비즈니스 담당자의 관심 상실
필요한 노력을 과소 평가	팀은 실패했다고 생각하고 일찍 실망합니다.