swtest

탐색적 테스팅 접근법 - Exploratory Testing approach


by Kitle · 2020. 08. 22.



탐색적 테스팅 -  Exploratory Testing approach

탐색적 테스팅이란 제품 정보 습득과 테스트 설계 그리고 테스트 실행을 동시에 수행하는 경험 기반의 테스트 접근법이라고 할 수 있습니다. '탐색적 테스팅' 은 경험기반 테스트로 보며 특별한 기술이 있는 '기법' 이라기 보다는 '접근법'으로 보는 것이 맞습니다. 현업에서는 뭐 그렇게 까지 철저히 구분하지는 않고 상황에 따라 '탐테' 하자 라고 하며 진행하도록 합니다. 철저하게 프로세스까지 만들어 하는 회사들은 흔치 않은 것 같네요.

명세기반 테스트는 주어진 명세가 잘 되어있고 탄탄할때 의미가 있지만, 현실 세계에서는 명세가 부족한거나 충격적으로 거의 없는 경우도 많이 존재 합니다. 또한 명세가 잘 되어있지만 개발시간이 촉박하게 주어지고 또 출시일이 고정된 상태에서 모든 테스트를 다 하기에는 또 부족한 것이 현실입니다. 


따라서 다음과 같은 상황이라면 탐색적으로 테스트를 진행하는 것이 좋습니다


탐색적 테스팅이 유용한 경우

테스트 시간이 부족할 때 

TC작성에 필요한 산출물 부족 할 때 

테스트 케이스 만으로는 만족스럽지 못할 때



탐색적 테스팅의 특징 

1. 테스터 개인의 지적능력 중시

-탐색(테스트)에서 얻은 정보로 제품 기능을 유추하거나 발견한 결함 정보나 유사 제품의 경험을 통해테스트 설계합니다.

2. 테스트 ‘실행’을 중시

-최소한의 산출물 작성을 권장하고 있습니다. 그렇다고 산출물이 없다는 것은 아닙니다.

3. ‘결함집중’의 원리에 충실

-결함이 집중된 부분을 식별하고 집중하면 테스트 발견에 효과적이다는 것에 충실합니다.

-예)심마니, 곰팡이

-심마니의 경우 하나의 삼을 발견하면 주변에 주변삼이 또 있는 경우가 많습니다. 곰팡이의 경우도 곰팡이가 발생한 주변에 집중적으로 곰팡이가 많은 경우가 많죠.

4. 작은 절차와 원리

-테스트 역량(경험)에 의존적입니다. 단점을 보완하기 위한 작은 절차만 두고 있습니다.

- 프로세스 : 테스트 계획 - 실행과 설계 - 종료


Test Charter

테스트 차터는 명확한 임무를 말합니다.

무엇을 어떻게 테스트 하는지에 대한 명명이라고 볼 수 있겠습니다,

예) ‘댓글 달기 기능을 테스트 한다’

예2) ‘댓글 달기 기능을 관리자 및 등록자 관점에서 테스트한다’


<21>Test Note

테스트한 기록을 남기는 수단을 테스트 노트라고 보시면 되겠습니다.

테스트 노트 예)



테스트 노트결과수행시간
1신규 게시글 작성 후 댓글 등록P10min
2댓글을 한 아이디로 반복 등록P10min
3댓글 단 아이디 탈퇴 후 댓글 확인F20mn
특이사항

삭제된 계정의 댓글을 지울 수없음

댓글 20개 이상은 스크롤이 너무 길어짐, 10개 정도로 Pagenation 필요





Time Boxing

실행시간을 제한하는 방법입니다.

실행 제한 시간= 세션당 60min ~ 120min. 을 권장합니다. 2시간까지는 좀 너무 긴 것 같고, 60-90분 정도가 실제 해 본결과 적절했다고 생각합니다.


회고 - Debriefings

결과를 공유하는 시간입니다. 회고 방식은 여러가지가 있으나 여기서는 PROOF 만 알아보겠습니다.

Past: 테스트 수행 내용(What happened during the testing?)

Results: 테스트 수행 성과(What was achieved during the testing?)

Outlook: 추가(보충)해야 할 사항(What still needs to be done?)

Obstacles: 개선이 필요한 요소(What got in the way of good testing?)

Feelings: 테스트 중 느낀 점(How does the tester feel about all this?)


탐색적 테스팅을 위한 회고

테스트 주요 내용 공유

발견한 주요 결함 공유

공유하고자 하는 이슈 사항

공유할 '테스트 아이디어'

를 공유하는게 좋습니다. 세번째 이슈 사항은 버그를 말하는 것이 아니라 진행이나 탐색적 테스트 진행 관련 이슈사항을 말해주는 것이 좋습니다. 그래야 진행 방식이나 세션등을 조율할 수 있습니다. 결함을 공유하다가 자연스럽게 테스트 아이디어가 공유되기도 하지만, 테스트 하면서 다른 부분(기능)이나 '다른 테스터가 이런 테스트 아이디어로 같이 테스트 해보면 좋을것 같은데' 라고 느끼는 부분이 있다면 공유하고 테스트를 확장시키는 것이 중요합니다. 위에서 말한 결함 집중의 원리에 충실할 수도 있고요.


탐색적 테스팅 프로세스

1. 계획 - 계획 수립(차터 작성 및 계획 수립)

2. 설계 & 실행 - 차터 테스트 수행, 테스트 노트 기록

3. 종료 - 테스트 회고, 종료 보고서 작성


탐색적 테스팅 계획 예
 - 신규 고객 상담 시스템 테스트 계획서 및 가용 리소스 확인 예


가용인원4인 ( 이팀장, 김대리, 테스터 A, 테스터 B)
일일 진행 챠터Short(30분) 6회, Normal(60분) 4회
일정테스트 케이스 문서가 넘어오기 전까지 수행(5일 예상)
총합78개 차터 실행예정, 실제로는 테스트 설정시간, 테스트 리포트 생성 시간을 고려필요

기능 구분 및 배정 예)

기능 명기능 설명배정 차터 배정인원
고객의 소리일반적인 고객 Q&A 상담 게시판20이팀장외 3
온라인 가입온라인 상에서 바로 가입이 가능한 기능16이팀장외 3
메일링고객 DB와 연계되어 정기적으로 홍보메일을 보내는 기능11김대리외 1
채팅실시간 온라인 채팅 기능10김대리외 1
기타오시는길, 연락처 확인10테스터 A

Lessons Learned

장점
 짧은 시간에 결함 발견 효과가 큼
 효율적인 테스트 실행
 명세 및 자원 부족시 활용
 공식적 테스트 커버리지 보완

단점
 테스터의 역량에 따라 서로 다른 결과(일관성 부족)
 테스트 커버리지 관점에서는 신뢰성 약함

실무활용 팁

실무에서는 TC를 보완할 목적으로 탐색적 테스트를 실시
자칫 잘 못 사용하는 경우는 시간 때우기가 될 수 있음(너무 짧은 차터 목표, 금방 끝나는 테스트, 결과에 대한 신뢰성(나온 버그가 없다고 한다면..?)
최소한의 관리와 피드백을 위해 차터 설계가 중요할 수 있음 - 역량이 높은 테스터에게는 위임
리스크가 높다고 생각되는 부분( 예) 새로 추가 된 기능 에 대해 적용하는 것이 한정된 자원을 잘 활용하는 방법일 수 있음)

참고 - Ad-hoc 테스트와 Random 테스트

ad-hoc 테스트

-"예상결과를 사전에 정의하지 않고, 자의적이고 임의적으로 실행하는 테스트 활동" 과는 차이가 있다. 

-이때 경험기반으로 테스트 해볼 수 있으나, 좀 더 목표 지향적이고 체계적으로 할 수 있도록 부분이 탐색적 테스팅 접근해 테스트하는 것을 탐색적 테스트라고 볼 수 있겠다.(개인의견)

Random 테스트

- "테스트 설계 기법을 통해 입력값을 따로 설정해 주지 않고 임의로 값을 선택해서 수행하는 방법" 과도 차이가 있다.