ISTQB 4.0 공부 ) 4장 4.4 경험기반 테스트 기법, 4.5 협업 기반 테스트 접근법에 대해 알아보자.

들어가기 전 알아둬야 할 4.4 용어 설명, 4.5 용어 설명
: 이해에 중점. 부족하면 용어설명 글 참고.

체크리스트 기반 리뷰 : 질문 목록이나 확인해야 하는 특성을 기반으로 수행하는 리뷰 기법.
체크리스트 기반 테스팅 : 경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 맟 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.

사용자 스토리 : 일상 또는 비즈니스 언어로 사용자가 필요로 하는 기능, 그것의 이유, 비기능 조건, 인구 조건 등을 포착하는 한 문장으로 구성된 사용자 또는 비즈니스 요구사항.

인수 조건 : 사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준.
시나리오 기반 리뷰 : 특정 시나리오를 처리할 수 있는 능력을 판단하기 위해 작업 산출물을 평가하는 리뷰 기법.
인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.

 

4.4 경험 기반 테스트 기법 
: 널리 사용하는 경험 기반 테스트 기법 3가지

• 오류 추정
• 탐색적 테스팅
• 체크리스트 기반 테스팅

4.4.1 오류 추정

< 오류 추정 >
: 테스터의 지식을 기본으로 오류, 결함, 발생을 예측하는 데 사용하는 기법.

>> 테스터의 지식
- 애플리케이션의 과거 동작.
- 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형.
- 다른 유사 애플리케이션에서 발생한 장애 유형.

일반적으로 오류, 결함, 장애는 입력, 출력, 논리, 계산, 인터페이스, 데이터와 관련이 있을 수 있다.

결함 공격 - 오류 추정을 구현하는 체계적인 접근법.
: 테스터가 발생 가능한 오류, 결함, 장애 목록을 만들거나 획득해서 오류와 관련된 결함을 식별 및 노출하거나, 장애를 유발하는 테스트를 설계하도록 한다.
ex. 목록 : 올바른 입력 허용 X, 잘못된 입력 허용 O. 출력형식 올바르지 않음. / 테스터가 이 목록으로 테스팅하는 경우 결함 공격 테스트 기법 사용.

 

4.4.2 탐색적 테스팅
: 테스터가 가지고 있는 경험, 지식, 그리고 호기심, 창의성들이 높으면 테스팅이 효과적!

< 탐색적 테스팅 >
- 테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 하게 된다.
- 테스트 대상에 대해 더 배우고, 집중하고 있는 테스트는 더 깊이 탐색하고, 테스트되지 않은 영역에 대한 테스트를 만들기 위해 사용.
- 테스트를 체계적으로 수행하기 위해 세션 기반 테스팅을 사용하기도 함.

▶ 탐색적 테스팅은
- 명세가 부족하거나 부적합할 경우, 테스트에 시간적 압박이 심할 때 유용!
- 다른 공식 테스트 기법을 보완하기에도 유용!
- 테스터가 풍부한 경험과 도메인 지식을 가지고 있고 높은 수준의 분석 기술, 호기심, 창의성 등 필요 기술을 갖춘 경우 더욱 효과적일 수 있다.

 

4.4.3 체크리스트 기반 테스팅
: 자동화 항목은 포함하면 x

< 체크리스트 기반 테스팅 >
- 테스터는 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행한다.
- 자동으로 점검할 수 있는 항목, 시작/ 종료 조건으로 더 적합한 항목, 너무 일반적인 항목은 체크리스트에 포함해서는 안된다.
- 체크리스트 항목을 질문 형식으로 표현하는 경우가 많음. 각 항목은 개별적이면서 직접적으로 확인할 수 있어야 한다. 이런 항목은 요구사항, 그래픽 인터페이스 속성, 품질 특성 또는 기타 유형의 테스트 컨디션일 수 있다.
- 시간이 지남에 따라 개발자가 같은 오류를 범하지 않게 됨으로 일부 체크리스트 항목은 점차 효과가 떨어질 수 있음. 결함 분석을 기반으로 정기적으로 업데이트 해야 함!!
- 구체적인 테스트 케이스가 없는 경우에 체크리스트 기반 테스팅은 일관성을 제공할 수 있다.
- 체크리스트가 상위 수준으로 작성된 경우 실제 테스트는 조금씩 달라질 수 있으며, 결국 커버리지는 높아지지만 재현 가능성은 떨어질 수 있다.

 

4.5 협업 기반 테스트 접근법
: 협업과 커뮤니케이션을 통한 결함 예방에 초점.

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

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

사용자 스토리의 3가지 중요 요소(== '3C')
카드(Card)	사용자 스토리를 설명하는 매체(ex. 인덱스 카드, 전자 게시판 항목)
대화(Conversation)	소프트웨어 사용 방법에 대한 설명(문서 또는 구두로)
확인(Confirmation)	인수 조건
사용자 스토리의 가장 일반적인 형식: "[역할]로서 [목표]를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기 원한다." 이며 이후 인수 조건이 뒤따르는 형식이다.

• 협업 기반 사용자 스토리 작성은 브레인스토밍, 마인드 매핑과 같은 기법을 사용. 협업을 통해 팀원들은 비즈니스, 개발, 테스팅의 세 가지 관점을 고려해 만들어서 전달할 것에 대한 공유된 비전을 얻을 수 있다.
• 좋은 사용자 스토리는 독립적이고 협상가능하고, 가치 있고, 추정 가능하고, 테스트 가능해야 한다.

4.5.2 인수 조건

사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건.
이런 관점에서 인수 조건을 테스트해야 하는 테스트 컨디션으로 볼 수 있다.

인수 조건은 보통 3C중 대화를 통해 결정된다.
인수 조건은 다음을 위해 사용된다.
1. 사용자 스토리 범위 정의.
2. 이해관계자 간 합의 도출.
3. 긍정과 부정 시나리오 설명.
4. 사용자 스토리 인수 테스팅의 베이시스 제공.
5. 정확한 계획 및 추정.

인수 조건 작성법 두가지
시나리오 기반	행위 주도 개발에서 사용하는 Given/ When/ Then.
규칙 기반	베리피케이션이 필요한 목록 또는 표로 표현된 입력-출력 매핑.

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

 

4.5.3 인수 테스트 주도 개발(ATTD)
: 테스트 우선 접근법.

테스트 케이스는 사용자 스토리 구현 전에 만들어진다. 고객, 개발자, 테스터 등 서로 다른 관점을 가진 팀원들이 테스트 케이스를 만든다.

첫 번째 단계 : 명세 워크숍으로 팀원들은 여기서 사용자 스토리와 인수조건을 분석하고 토론해서 작성. 이 과정에서 사용자 스토리의 불완전성, 모호성, 결함을 해결하게 된다.
두 번째 단계 : 테스트 케이스를 만드는 것. 이 작업은 팀 전체가 수행하거나 테스터가 개별적으로 수행할 수 있다. 테스트 케이스는 인수 조건을 기반으로 하며, 소프트웨어가 어떻게 작동하는지에 대한 예제로 볼 수 있다. 이는 팀이 사용자 스토리를 올바르게 구현하는데 도움을 준다.

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