노년코딩

4.3.3 경험 기반 기법(Experience-based)

▶ 경험 기반 테스팅
 - 이전에 테스터가 다루었던 유사 어플이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스 추출.
 - 공식적인 방식 아닌 특별한 테스트 케이스를 찾아내고 실행하는 데 유용 -- > 공식적인 기법과 같이 사용해야 효과적
 - 경험에 따라 효율성 및 효과성의 정도가 매우 달라짐(일관성 떨어짐)
 - 테스트 케이스를 문서화함
 - 또 다른 말로 에러 추정(Error guessing) 또는 탐색적 테스팅(Exploratory Testing) 접근법이라 함

4.3.3.1 탐색적 테스팅 기법

▶ 탐색적 테스팅 : 기법이 아닌 접근법
 - 테스트 케이스 작성 시간을 최소화하고 테스트 엔지니어의 발견적인(heuristic) 지적능력을 최대한 활용하여 테스트 수행
 - 다른 명칭으로 에드혹, 게릴라, 직관적 테스팅과 유사한 개념
   >> But, 정해진 임무와 목표, 결과물이 존재
 - 테스트를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서 익숙해지는 동시에 테스트를 설계하고 테스트를 계획한다.
   >> 테스트 차터를 기반으로 수행(60 ~ 120분 동안 몰입해서 수행)
   >> 제한된 시간(time-boxing)내에 테스팅의 목적을 정한 후  몰입하여 최소한의 설명 가능한 기록(note)을 남기며 테스트 수행하고, 수행 후 요약보고(debriefing)를 하는 것을 강조.
▶ 탐색적 테스팅
 - 경험적인 요소를 많이 반영하고 있는 체계화된 테스팅 접근법
 - 테스트 케이스 작성(문서화)하는데 들이는 노력을 최소화
 - 테스트 설계와 실행 최대화
 - 점진적 & 주기적 테스팅
▶ 탐색적 테스팅 절차
 - 제품의 목적 식별
 - 기능 식별
 - 잠재적으로 불안정한 부분 식별
 - 각각의 기능 테스트 및 문제점 기록
 - 일관성 검증 테스트 설계 및 기록
▶ 탐색적 테스팅의 구성 요소 (테스터 차터 >> 테스트 노트 >> 타임 박싱 >> 회고)
 - 테스터 차터
   >> 제품의 어느 부분을 어떻게 테스트하고 어떤 것을 중점적으로 봐야 할지 등을 기록한 테스트 명령지
   >> 각 세션에 대해 명확한 임무를 설정
 - 테스터가 수행할 내용
   >> 정확한 리포팅
   >> 유연성 있는 일정 관리
   >> 테스트 방향 정정
   >> 견고한 테스팅
   >> 효율적인 요약 보고
- 테스트 노트
   >> 테스트 실행과 동시에 계획, 설계, 테스트 케이스 작성 --> 노트화 함
   >> 테스트 기록 및 발견 특이사항과 실행시간 등 기재 --> 테스트 케이스
   >> 내용 : 테스트한 제품에 대한 노트 및 기록, 발견한 결함과 장애에 대한 노트 및 기록, 어떻게 테스트하였는지를 기술하는 요약된 문서.
- 타임 박싱(60분 ~ 120분)
   >> 테스트 집중력을 높이기 위해 테스트 시간을 제한
   >> 테스트 시간을 제한하면 집중력이 높아지며, 테스트 일정 수립도 쉬움
- 회고(요약보고 - debriefing)
   >> 테스트 중 발견했던 결함과 이슈사항에 대해 보고
   >> 테스터의 경험과 지식을 공유
   >> 문서화 
▶ 테스트 케이스 기반 테스팅과 탐색적 테스팅 비교
 - 테스트 제품을 파악해 가면서 테스트 실시
 - 탐색적 테스트는 테스터의 성향에 많이 의존적임
 - 문서화 정도와 지적 능력의 활용 정도에 따른 비교 

   >> 테스팅 케이스 기반(연설문을 만든다 -문서화하는 능력) - 문서화가 잘 돼있을수록 테스트케이스 기반 테스팅 할 수 있음.
   >> 탐색적 테스팅(경험에 의해 하는거 - 지적 능력) - 지적능력이 있을수록 탐색적 테스팅할 수 있음.
 - 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교 (밑에 표)

▶ 리스크 기반 테스팅과 연계한 탐색적 테스팅의 활용
 - 리스크 기반 전략에서의 탐색적 테스팅 접근법 활용 
테스트 전력 수립 시 제품의 리스크가 가장 높은 곳에 탐색적 테스팅을 추가, 그다음 높은 곳에 선택적 탐색적 테스팅 추가. 리스크가 가장 높은 곳에 테스팅 경험이 풍부하고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행하여야 함. 반대로 리스크가 가장 낮은 곳에 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행.
▶ 탐색적 테스팅 효과
 - 경험적 테스팅을 체계화 시킬 수 있음.
 - 테스트 케이스 작성 시간을 줄여 좀 더 많은 테스트 가능
 - 테스터 또는 테스트 엔지니어의 역량을 강화할 수 있음.
 - 적은 테스트 인력으로 많은 테스트를 수행할 수 있음.
 - 명세가 없고 시간 부족인 경우 테스트를 효과적으로 효율적으로 수행할 수 있음.

4.4.1 명세 기반 기법 - 분류 트리 기법

▶ 분류 트리 기법
 - 소프트웨어 일부 또는 전체를 트리구조로 분석 및 표현하고 이를 바탕으로 테스트 케이스를 도출하는 기법.

 < 분류 트리의 장점 >
1. 시각화해서 테스트 케이스 작성에 용이.
2. 트리 구조이므로 중복되거나 빠지는 테스트가 없음.
3. 복잡한 시스템이나 어플리케이션의 일부 또는 전체를 테스팅.
4. 개발 설계를 체크하는 용도로 사용이 가능함.
5. 테스트 케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능함.

4.3.1.4 상태 전이 테스팅

▶ 상태 전이 테스팅 (state trasition)

 - 이벤트, 액션, 상태, 가드, 상태전이 사이의 관계를 검증.

 - 시스템/SW의 상태 기반 행위가 명세화(글자로 쓰여있던)된 내용과 일치함을 검증.

 - 상태기반 시스템의 결함은 상태, 상태전이, 가드, 이벤트 결함 등으로 분류.

 - "구현이 잘못된 경우"와 "명세가 잘못된 경우"의 결함으로 구분.

 - 모델(명세)상의 결함 -- > 인스펙션, 정적 분석으로 결함 발견.

   >> 초기 상태 누락

   >> 전이 또는 액션의 누락

   >> 가드를 "전이" 대신 상태에 표기

   >> 가드의 중복 또는 불일치

 - 구현상의 결함 -- > 테스트를 통해 결함 발견

   >> 여분/ 누락/ 훼손 상태(extra/ missing/ corrupt state)

   >> 액션이 틀리거나 누락됨

   >> 스니크 패스(sneak paths), 트랩 도어(trap doors)

      - 설계할 때 의도하지 않았으나 발생하여 정상적인 작동에 손상을 주는 경로.

• 상태 다이어그램 표기법

• 상태: [대기], [금액 투입], [음료 선택]
• [대기] 이벤트 : ev 금액투입[투입금액 < 가격], ev 금액투입[투입금액 >= 가격]
• [금액 투입] 이벤트 : ev 취소, ev 금액투입[투입금액 >= 가격], ev 금액투입[투입금액 < 가격]
• [음료 선택] 이벤트 : ev 취소, ev 음료버튼 선택

▶ 상태전이 테스트 케이스 절차

1. 상태-이벤트 테이블 구성
2. 전이 트리 구성
3. 반응(Legal, 또는 유효(Valid)) 테스트 케이스 구성
4. 무반응(Illegal, 또는 비유효(Invalid)) 테스트 케이스 구성
5. 가드(Guard) 또는 조건 테스트 케이스 구성
6. 테스트 프로시저(Test procedure) 구성

자판기로 상태전이 테스트 케이스를 알아보자.

1. 상태-이벤트 테이블

* 동일한 이벤트지만 가드가 다르면, 서로 다른 이벤트로 구분해 상태-이벤트 테이블을 작성한다.

2. 전이 트리 구성

3. 반응(유효) 테스트 케이스

* 음료가격 700원으로 가정

4. 무반응(비유효) 테스트 케이스

불가능한 상황들을 만들어서 테스트를 해보는 것.

5. 가드 테스트 케이스

* 음료가격 700원으로 가정 / 조건에 따라 기대결과가 달라짐.

6. 테스트 프로시저 구성  ( *가능한 겹치지 않으면서 내가 할 수 있는 모든 테스트 케이스를 만들어야 돼. )

• TP1 = V001 -> IV001 -> IV002 -> V002 -> V003 -> V006 -> V007 -> V010
• TP2 = V004 -> IV003 -> V011 -> V005
• TP3 = V008 -> V009 -> V013 -> V016 -> V012
• TP4 = V014 -> V004 -> G001 -> G002
• TP5 = V015 -> IV004 -> IV005