4.5. 협업 기반 테스트 접근법

4장에서 언급한 테스트 접근방법은 결함 식별과 관련해 목표를 가지지만협업 기반 접근법은 협업과 커뮤니케이션을 통한 결함 예방에도 초점을 둔다.

4.5.1. 협업 기반 사용자 스토리 작성

사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.

*3C 구성 요소 *

• 카드 (Card): 사용자 스토리를 설명하는 매체 (예: 인덱스 카드, 전자 게시판 항목)
• 대화 (Conversation): 소프트웨어 사용 방법에 대한 설명
• 확인 (Confirmation): 인수 조건

*형식 : * "[역할]로서 [목표]를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기를 원한다." 이후 인수 조건이 뒤따른다.

*협업 방법 : * 브레인스토밍, 마인드 매핑 등을 사용하여 비즈니스, 개발, 테스팅의 세 가지 관점을 고려해 공유된 비전을 얻는다.

좋은 사용자 스토리의 특성

• 독립적 (Independent)
• 협상 가능 (Negotiable)
• 가치 있음 (Valuable)
• 추정 가능 (Estimable)
• 작음 (Small)
• 테스트 가능 (Testable)

*주의 사항 : * 사용자 스토리가 명확하지 않거나 중요한 내용을 반영하지 않는다면, 이해관계자가 테스트 방법을 모르거나 도움이 필요할 수 있다

4.5.2. 인수 조건

정의
사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건.

결정 방법
인수 조건은 보통 '3C' 중 대화(Conversation)를 통해 결정된다.

사용 목적

• 사용자 스토리 범위 정의
• 이해관계자 간 합의 도출
• 긍정과 부정 시나리오 설명
• 사용자 스토리 인수 테스팅의 베이시스 제공
• 정확한 계획 및 추정

작성 방법
다양한 사용자 스토리의 인수 조건 작성법이 있으며, 가장 일반적인 두 가지 방법은 아래와 같다.

• 시나리오 기반: 예: 행위 주도 개발에서 사용하는 Given/When/Then 형식
• 규칙 기반: 예: 베리피케이션이 필요한 목록 또는 표로 표현된 입력-출력 매핑

대부분의 인수 조건은 이 두 가지 형식 중 하나로 문서화할 수 있다. 그러나 팀이 다른 자체 형식을 사용하기로 할 수도 있으며, 이때도 인수 조건이 잘 정의되어 모호하지 않아야 한다.
ㅈㅈㅈㅈㅈ

4.5.3. 인수 테스트 주도 개발(ATTD)

정의
인수 테스트 주도 개발은 테스트 우선 접근법이다. 테스트 케이스는 사용자 스토리 구현 전에 작성된다.

참여자
고객, 개발자, 테스터 등 다양한 관점을 가진 팀원들이 테스트 케이스를 만든다

과정

• 명세 워크숍
  • 팀원들이 사용자 스토리와 인수 조건을 분석하고 토론하여 작성한다.
  • 사용자 스토리의 불완전성, 모호성, 결함을 해결한다.
• 테스트 케이스 작성
  • 팀 전체가 수행하거나 테스터가 개별적으로 수행할 수 있다.
  • 테스트 케이스는 인수 조건을 기반으로 하며, 소프트웨어의 작동 방식에 대한 예제로 볼 수 있다.
• 테스트 설계
  • 긍정/유효 테스트 케이스: 예외나 오류 조건 없이 올바른 동작을 확인.
  • 비유효/부정 테스트 케이스: 예외나 오류 조건을 포함.
  • 비기능 품질 특성 테스트: 성능 효율성, 사용성 등을 다룬다.

특징

• 테스트 케이스는 이해관계자가 이해할 수 있는 방식으로 표현되어야 한다.
• 필요한 전제 조건, 입력값, 사후 조건 등을 포함하여 자연어 문장으로 작성한다.
• 테스트 케이스는 사용자 스토리의 모든 특성을 다루며, 스토리를 벗어나지 않아야 한다.
• 두 개 이상의 테스트 케이스가 같은 특성을 설명해서는 안 된다.

자동화

• 테스트 자동화 프레임워크가 지원하는 형식으로 작성하면, 개발자는 필요한 코드를 작성하여 테스트 케이스를 자동화할 수 있다.
• 인수 테스트는 실행 가능한 요구사항이 된다.

예상문제

문제 1: 협업 기반 사용자 스토리 작성의 '3C' 요소가 아닌 것은 무엇인가?

A) 카드 (Card)
B) 대화 (Conversation)
C) 확인 (Confirmation)
D) 코드 (Code)

정답(드래그)
　D　
해설(드래그)
3C 요소는 카드 (Card), 대화 (Conversation), 확인 (Confirmation)이다.

문제 2: 좋은 사용자 스토리의 특성이 아닌 것은 무엇인가?

A) 독립적 (Independent)
B) 협상 가능 (Negotiable)
C) 상세하고 길다 (Detailed and Long)
D) 테스트 가능 (Testable)

정답(드래그)
　C　
해설(드래그)
좋은 사용자 스토리는 독립적이고 협상 가능하며 가치 있고 추정 가능하며 작고 테스트 가능해야 한다. 상세하고 길지는 않아야 한다.

문제 3: 협업 기반 사용자 스토리 작성에서 사용하는 기법이 아닌 것은 무엇인가?

A) 브레인스토밍
B) 마인드 매핑
C) 회귀 분석
D) 스토리보드 작성

정답(드래그)
　C　
해설(드래그)
회귀 분석은 데이터 분석 기법으로, 협업 기반 사용자 스토리 작성에서 일반적으로 사용되지 않는다.

문제 4: 인수 조건에 대한 설명으로 옳지 않은 것은 무엇인가?

A) 사용자 스토리 구현 결과를 승인하기 위해 충족되어야 하는 조건이다.
B) 인수 조건은 보통 대화를 통해 결정된다.
C) 인수 조건은 사용자 스토리의 범위를 정의하는 데 사용된다.
D) 인수 조건은 항상 규칙 기반 형식으로 작성된다.

정답(드래그)
　D　
해설(드래그)
인수 조건은 시나리오 기반 또는 규칙 기반 형식으로 작성될 수 있으며, 항상 규칙 기반 형식으로 작성되는 것은 아니다.

문제 5: 인수 조건이 사용되는 목적이 아닌 것은 무엇인가?

A) 사용자 스토리 범위 정의
B) 이해관계자 간 합의 도출
C) 사용자 스토리의 개발 시간 단축
D) 긍정과 부정 시나리오 설명

정답(드래그)
　C　
해설(드래그)
인수 조건은 사용자 스토리의 범위 정의, 이해관계자 간 합의 도출, 긍정과 부정 시나리오 설명, 인수 테스팅의 베이시스를 제공하는 데 사용된다.

문제 6: 인수 조건 작성 방법 중 하나가 아닌 것은 무엇인가?

A) 시나리오 기반
B) 규칙 기반
C) 인터페이스 기반
D) 입력-출력 매핑

정답(드래그)
　C　
해설(드래그)
인수 조건 작성 방법으로는 시나리오 기반과 규칙 기반이 있다. 인터페이스 기반은 포함되지 않는다.

문제 7: 인수 테스트 주도 개발(ATTD)에 대한 설명으로 옳지 않은 것은 무엇인가?

A) 테스트 케이스는 사용자 스토리 구현 전에 작성된다.
B) 테스트 케이스는 고객, 개발자, 테스터가 함께 만든다.
C) 첫 번째 테스트 케이스는 항상 부정 테스트 케이스이다.
D) 명세 워크숍에서 사용자 스토리와 인수 조건을 분석하고 토론한다.

정답(드래그)
　C　
해설(드래그)
첫 번째 테스트 케이스는 올바른 동작을 확인하는 긍정/유효 테스트 케이스로 작성된다.

문제 8: ATTD 과정에서 수행되는 단계가 아닌 것은 무엇인가?

A) 명세 워크숍
B) 테스트 케이스 작성
C) 코드 리뷰
D) 비기능 품질 특성 테스트

정답(드래그)
　C　
해설(드래그)
코드 리뷰는 ATTD 과정에서 직접적으로 수행되지 않는다.

문제 9: ATTD에서 테스트 케이스 작성 시 유의해야 할 사항이 아닌 것은 무엇인가?

A) 테스트 케이스는 인수 조건을 기반으로 작성한다.
B) 테스트 케이스는 이해관계자가 이해할 수 있는 방식으로 표현되어야 한다.
C) 두 개 이상의 테스트 케이스가 같은 특성을 설명할 수 있다.
D) 테스트 케이스는 자연어 문장으로 구성된다.

정답(드래그)
　C　
해설(드래그)
두 개 이상의 테스트 케이스가 같은 특성을 설명해서는 안 된다.

문제 10: ATTD에서 긍정/유효 테스트 케이스에 해당하는 설명으로 옳은 것은 무엇인가?

A) 예외나 오류 조건을 포함한다.
B) 올바른 동작을 확인한다.
C) 비기능 품질 특성을 다룬다.
D) 모든 특성을 설명하지 않는다.

정답(드래그)
　B　
해설(드래그)
긍정/유효 테스트 케이스는 예외나 오류 조건 없이 올바른 동작을 확인하는 테스트 케이스이다.