명확히 이해 관계자의 요구 사항은 높은 수준의 목표입니다. AC 의 목적을 명확하게하기 위해,그것들을 무너 뜨리자.

기능 범위 detalization. AC 는 사용자 스토리의 경계를 정의합니다. 그들이 제공하는 정확한 정보에 기능하는 데 도움이 팀을 이해하는지 여부를 이야기가 완료되고 예상대로 작동합니다.

부정적인 시나리오를 설명합니다. Yor AC 는 시스템이 안전하지 않은 암호 입력을 인식하고 사용자가 더 이상 진행하지 못하도록 요구할 수 있습니다., 잘못된 암호 형식은 사용자가 잘못된 입력을 수행하거나 예기치 않게 동작 할 때 소위 부정적인 시나리오의 예입니다. AC 는 이러한 시나리오를 정의하고 시스템이 어떻게 반응해야하는지 설명합니다.

설정 통신. 수락 기준은 클라이언트와 개발 팀의 비전을 동기화합니다. 그들은 그들 모두가 일반적인 이해의 요구 사항:개발자가 정확히 어떤 종류의 행동 기능을 입증해야 합하는 동안,이해관계자들과 클라이언트 무엇이에서 예상되는 특징이 있습니다.

합리화 수용 테스트., AC 는 사용자 스토리 수용 테스트의 기초입니다. 각 수락 기준은 독립적으로 테스트 할 수 있어야하므로 명확한 통과 또는 실패 시나리오가 있어야합니다. 그들은 또한 자동화 된 테스트를 통해 이야기를 확인하는 데 사용될 수있다.

특징 추정. 수락 기준은 팀이 정확히 개발해야하는 것을 지정합니다. 팀이 정확한 요구 사항을 갖게되면 사용자 스토리를 올바르게 추정 할 수있는 작업으로 분할 할 수 있습니다.

수용 기준 유형 및 구조

AC 는 다른 형식으로 작성할 수 있습니다., 두 가지 가장 일반적인 사람,그리고 세 번째 옵션을 고안하는 것입니다 당신의 자신의 형식

  • 시나리오 중심의(주어진 때 다)
  • 규칙을 중심의(체크리스트)
  • 사용자 정의 형식

으로 첫 번째와 두 번째 형식은 매우 특정 구조물,우리는 대부분 그들에 초점을 맞 춥니 다. 그러나,당신이 찾을 수 있는 기타 형식에 맞게 제품을 더 나은 그래서 우리는 잠시 접촉뿐만 아니라 그들에.

시나리오 지향 수용 기준

시나리오 지향 형식 쓰기 AC 는 주어진/When/Then(GWT)유형으로 알려져 있습니다.,

  • 주어진 일부 전제조건
  • 때 나는 몇 가지 동작
  • 그때 나는 어떤 결과

이 접근 방식을 상속에서 동작 중심의 개발(BDD)제공하는 일관된 구조는 데 도움이 테스터를 정의할 때 시작하고 종료하는 테스트는 특정 기능입니다. 또한 시스템의 동작이 선불로 설명되므로 테스트 케이스 작성에 소요되는 시간이 줄어 듭니다.,

각각의 승인 기준에 기록 된 이 형식은 다음과 같은 문구:

  1. 시나리오의 이름을하는 동작을 설명한
  2. 어—시작 부분의 상태 시나리오
  3. 경우 특정 조치는 사용자가
  4. —다음의 결과는 액션에서”때에”
  5. 그리고—사용되는 계속하려면 모든 세 개의 이전 문

결합했을 때 이러한 문을 커버하는 행위를 하지 않는 사용자 작업을 완료하는 데 걸리는 시간을 경험한 결과입니다.

몇 가지 예를 살펴 보겠습니다.,암호를 잊어 버린 경우를 대비하여 내 계정에 액세스 할 수 있도록 내 계정에 암호를 복구 할 수 있기를 원합니다.,igated 로그인 페이지.

경우:사용자가 선택한 암호를 잊어버렸 옵션

과:입력한 이메일을받을 수 링크에 대한 비밀번호 복

그리 시스템 링크를 전송하는 입력한 이메일

주:사용자를 받은 링크를 이메일을 통해

경우: 사용자가 탐색하는 링크를 통해서 받은 이메일

그리 시스템 사용자를 설정하는 새로운 비밀번호

예제 2

사용자 이야기:으로 사용하고 싶을 요청할 수 있는 현금부터 내 계정에서 ATM 도록 할 수 있을 받 내 계좌에서 돈을 신속하고 다양한 장소에 저장됩니다.,alid

와:디스펜서 포함되는 현금

경우:고객이 요청하는 현금

다하는 계정이 청구됩

과:도록금 분배되

고:카드를 반환

합격 기준 2:

정: 는 계정을 대 월

고:카드의 유효

경우:고객이 요청하는 현금

그는지 확인 거절 메시지가 표시됩니다.

과:도록 현금지 않는 분배된

규칙을 지향적이 합격기준 형식

어떤 경우에, 그것은 어렵에 맞는 승인 기준으로 주어진 때 다음 구조입니다., 예를 들어,GWT 할 수 있용은 다음과 같은 경우:

  • 작업 중 사용자와 이야기를 설명하는 시스템 레벨 기능을 필요로 하는 다른 방법의 품질을 보증합니다.
  • 수용 기준에 대한 대상 고객은 테스트 시나리오의 정확한 세부 정보가 필요하지 않습니다.
  • GWT 시나리오는 기능의 디자인 및 사용자 경험 제약 조건을 설명하는 데 적합하지 않습니다. 개발자는 여러 가지 중요한 세부 사항을 놓칠 수 있습니다.

규칙 지향 AC 형식으로 이러한 사례를 해결할 수 있습니다.,

규칙 지향 형식은 시스템의 동작을 설명하는 일련의 규칙이 있음을 수반합니다. 이러한 규칙에 따라 특정 시나리오를 그릴 수 있습니다.

일반적으로이 양식을 사용하여 구성된 기준은 간단한 글 머리 기호 목록처럼 보입니다. 예제를 살펴 보겠습니다.

예

사용자 이야기:사용자로 사용하고 싶 검색 필드를 입력,도시 이름을,또는 스트리트,그래서 찾을 수 있는 일치하는 호텔 옵션입니다.,

기초 검색 인터페이스는 승인 기준

  • 검색 분야에 위치 상위 바
  • 검색을 시작하면 사용자 클릭하”검색”
  • 분야가 포함 자리 표시자로 회색 색 text:”어디로 가나?”
  • 자리 표시자가 사라지면 사용자 입력을 시작
  • 검색이 수행된 경우에는 사용자 유형,도시에서 호텔 이름,거리,또는 모든 결합된
  • 검색에서 영어,프랑스어,독일어,그리고 우크라이나
  • 사용자가 입력할 수 없습 200 개 이상의 기호
  • 검색을 지원하지 않는 특별한 기호(문자)., 사용자가 특수 기호를 입력 한 경우”검색 입력에 특수 기호를 포함 할 수 없습니다.”

기타 형식

대부분의 사용자 이야기할 수 있으로 덮여 두 개의 포맷으로 위에서 언급된다. 그러나,당신은 당신의 자신의 발명 승인 기준을 주어 그들은 그들의 목적으로는 명확하게 기록하는 일반 영어 수 없음을 잘못 해석됩니다. 일부 팀은 일반 텍스트를 사용하기도합니다.

때때로,당신의 기준은 시스템 동작의 예로서 지정 될 수있다: