ISTQB - CTFL [테스트 분석과 설계] 협업 기반 테스트 접근법 정리

협업 기반 접근법은 협업과 커뮤니케이션을 통한 결함 예방에도 초점을 둔다.

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

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

사용자 스토리는 다음 세 가지 중요 요소를 가지고 있으며 이를 '3C'라고 부른다.

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

사용자 스토리의 가장 일반적인 형식은 "[역할]로서 [목표]를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기를 원한다."이며, 이후 인수 조건이 뒤따르는 형식이다.

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

브레인스토밍, 마인드 매핑과 같은 기법을 사용한다.

협업을 통해 팀원들은 비즈니스, 개발, 테스팅의 세 가지 관점을 고려해 만들어서 전달할 것에 대한 공유된 비전을 얻을 수 있다.

좋은 사용자 스토리

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

위의 조건들을 만족해야 한다.(INVEST)

이해 관계자가 사용자 스토리를 테스트하는 방법을 모른다면?

• 그 사용자 스토리가 명확하지 않거나
• 사용자에게 중요한 내용이 반영되어 있지 않거나
• 이해관계자가 테스트를 수행하는 데 있어 도움이 필요하다는 것을 의미

인수 조건

• 사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건이다.
• 이런 관점에서 인수 조건을 테스트해야 하는 테스트 컨디션으로 볼 수 있다.
• 인수 조건은 보통 3C 중 대화(Conversation)을 통해 결정된다.

인수 조건은 다음을 위해 사용된다.

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

다양한 사용자 스토리의 인수 조건 작성법이 있다.

가장 일반적인 두 가지 작성법

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

대부분의 인수 조건은 이 두 가지 형식 중 하나로 문서화할 수 있다.

그러나 팀이 다른 자체 형식을 사용하기로 할 수 있으며, 이때도 인수 조건이 잘 정의되어 모호하지 않아야 한다.

인수 테스트 주도 개발(ATDD) - Acceptance Test Driven Development)

• 테스트 우선 접근법이다.
• 테스트 케이스는 사용자 스토리 구현 전에 만들어진다.
• 고객, 개발자, 테스터 등 서로 다른 관점을 가진 팀원들이 테스트 케이스를 만든다.
• 테스트 케이스는 수동 또는 자동으로 실행할 수 있다.

첫 번째 단계

• 명세 워크숍으로 팀원들은 여기서 사용자 스토리와 (아직 정의되지 않은 경우) 인수 조건을 분석하고 토론해서 작성한다.
• 이 과정에서 사용자 스토리의 불완전성, 모호성 결함을 해결하게 된다.

두 번째 단계

• 테스트 케이스 만들기
• 이 작업은 팀 전체가 수행하거나 테스터가 개별적으로 수행할 수 있다. 
• 테스트 케이스는 인수 조건을 기반으로 하며, 소프트웨어가 어떻게 작동하는지에 대한 예제로 볼 수 있다.
• 이는 팀이 사용자 스토리를 올바르게 구현하는 데 도움을 준다.

테스트 설계 시 블랙박스, 화이트박스, 경험기반 테스트 기법을 적용할 수 있다. 

• 일반적으로 첫 번째 테스트 케이스는 예외나 오류 조건 없이 올바른 동작을 확인하고 모든 것이 예상대로 진행될 경우 실행되는 일련의 활동으로 구성된 긍정/유효 테스트 케이스이다.
• 유효 테스트 케이스를 끝내고 나면 팀은 비유효/부정 테스트를 수행해야 한다.
• 마지막으로, 팀은 비기능 품질 특성들(성능 효율성, 사용성)도 다루어야 한다.
• 테스트 케이스는 이해관계자가 이해할 수 있는 방식으로 표현되어야 한다.
• 일반적으로 테스트 케이스는 (있는 경우) 필요한 전제 조건, 입력값, 사후 조건을 포함하며 자연어 문장으로 구성한다.
• 테스트 케이스는 사용자 스토리의 모든 특성을 다뤄야 하며 스토리를 벗어나면 안 된다.
• 그러나 인수 조건이 사용자 스토리가 얘기하는 문제의 일부를 구체적으로 설명할 수도 있다.
• 또한, 두 개 이상의 테스트 케이스가 사용자 스토리의 같은 특성을 설명해서는 안 된다.
• 테스트 자동화 프레임워크가 지원하는 형식으로 작성하면 개발자는 사용자 스토리에서 설명하는 기능을 구현할 때 필요한 코드를 작성해 테스트 케이스를 자동화할 수 있다. → 그러면 인수 테스트가 실행 가능한 요구사항이 된다.

---

Reference

https://www.kstqb.org/sw/sw3.asp

KSTQB