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 WellTest Often.

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

살아있는 문서

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

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

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

안티 패턴

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

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

안티 패턴 문제점
협업 없음
  • 많은 가정

  • 잘못된 것을 구축

  • 잘못된 것을 테스트

  • 코드가 완료되면 인식하지 못함

코드가 완료되면 인식하지 못함
  • 테스트 유지하기 어려움

  • 이해하기 어려운 사양

  • 비즈니스 담당자의 관심 상실

너무 상세하거나 UI 중심적인 예
  • 테스트 유지하기 어려움

  • 이해하기 어려운 사양

  • 비즈니스 담당자의 관심 상실

필요한 노력을 과소 평가
  • 팀은 실패했다고 생각하고 일찍 실망합니다.

문제 해결-품질

안티 패턴에 시계를 유지하여 품질을 보장 ​​할 수 있습니다. 안티 패턴으로 인해 발생하는 문제를 최소화하려면 다음을 수행해야합니다.

  • 함께 모여 예제를 사용하여 지정하십시오.

  • 예제를 정리하고 개선하십시오.

  • 예제를 만족하는 코드 작성

  • 예제를 자동화하고 배포합니다.

  • 모든 사용자 스토리에 대해 접근 방식을 반복하십시오.

안티 패턴으로 인한 문제를 해결하려면 다음을 준수해야합니다.

  • Collaboration.

  • 무엇에 집중합니다.

  • 비즈니스에 집중.

  • 준비하십시오.

위의 각각의 의미를 이해합시다.

협동

협력-

  • 비즈니스맨, 개발자 및 테스터는 자신의 관점에서 의견을 제공합니다.

  • 자동화 된 예제는 팀이 올바른 것을 구축했음을 증명합니다.

  • 프로세스는 테스트 자체보다 더 가치가 있습니다.

무엇에 집중

'무엇'이라는 질문에 집중해야합니다. '무엇'에 집중하면서-

  • 가능한 모든 경우를 다루려고하지 마십시오.

  • 다른 종류의 테스트를 사용하는 것을 잊지 마십시오.

  • 가능한 한 간단한 예를 유지하십시오.

  • 예제는 시스템 사용자가 쉽게 이해할 수 있어야합니다.

  • 도구는 워크숍에서 중요한 역할을해서는 안됩니다.

비즈니스에 집중

비즈니스에 집중하려면-

  • 비즈니스 의도에 따라 사양을 유지하십시오.

  • 사양을 만들고 검토 할 때 비즈니스를 포함합니다.

  • 자동화 레이어의 모든 세부 정보를 숨 깁니다.

준비하라

다음에 대비하십시오-

  • 팀 관행이 변경되는 동안에도 이점은 즉시 드러나지 않습니다.

  • SbE를 소개하는 것은 어렵습니다.

  • 시간과 투자가 필요합니다.

  • 자동 테스트는 무료가 아닙니다.

도구

도구 사용은 실제로 여러 도구를 사용할 수 있지만 예제 별 사양에서는 필수가 아닙니다. 도구를 사용하지 않아도 예제 별 사양에 따라 성공한 경우가 있습니다.

다음 도구는 예제로 사양을 지원합니다-

  • Cucumber

  • SpecFlow

  • Fitnesse

  • Jbehave

  • Concordion

  • Behat

  • Jasmine

  • Relish

  • Speclog