swtest
탐색적 테스팅 접근법 - Exploratory Testing approach
by Kitle · 2020. 08. 22.
탐색적 테스팅 - Exploratory Testing approach
탐색적 테스팅이란 제품 정보 습득과 테스트 설계 그리고 테스트 실행을 동시에 수행하는 경험 기반의 테스트 접근법이라고 할 수 있습니다. '탐색적 테스팅' 은 경험기반 테스트로 보며 특별한 기술이 있는 '기법' 이라기 보다는 '접근법'으로 보는 것이 맞습니다. 현업에서는 뭐 그렇게 까지 철저히 구분하지는 않고 상황에 따라 '탐테' 하자 라고 하며 진행하도록 합니다. 철저하게 프로세스까지 만들어 하는 회사들은 흔치 않은 것 같네요.
명세기반 테스트는 주어진 명세가 잘 되어있고 탄탄할때 의미가 있지만, 현실 세계에서는 명세가 부족한거나 충격적으로 거의 없는 경우도 많이 존재 합니다. 또한 명세가 잘 되어있지만 개발시간이 촉박하게 주어지고 또 출시일이 고정된 상태에서 모든 테스트를 다 하기에는 또 부족한 것이 현실입니다.
따라서 다음과 같은 상황이라면 탐색적으로 테스트를 진행하는 것이 좋습니다
탐색적 테스팅이 유용한 경우
테스트 시간이 부족할 때
TC작성에 필요한 산출물 부족 할 때
테스트 케이스 만으로는 만족스럽지 못할 때
탐색적 테스팅의 특징
1. 테스터 개인의 지적능력 중시
-탐색(테스트)에서 얻은 정보로 제품 기능을 유추하거나 발견한 결함 정보나 유사 제품의 경험을 통해테스트 설계합니다.
2. 테스트 ‘실행’을 중시
-최소한의 산출물 작성을 권장하고 있습니다. 그렇다고 산출물이 없다는 것은 아닙니다.
3. ‘결함집중’의 원리에 충실
-결함이 집중된 부분을 식별하고 집중하면 테스트 발견에 효과적이다는 것에 충실합니다.
-예)심마니, 곰팡이
-심마니의 경우 하나의 삼을 발견하면 주변에 주변삼이 또 있는 경우가 많습니다. 곰팡이의 경우도 곰팡이가 발생한 주변에 집중적으로 곰팡이가 많은 경우가 많죠.
4. 작은 절차와 원리
-테스트 역량(경험)에 의존적입니다. 단점을 보완하기 위한 작은 절차만 두고 있습니다.
- 프로세스 : 테스트 계획 - 실행과 설계 - 종료
Test Charter
테스트 차터는 명확한 임무를 말합니다.
무엇을 어떻게 테스트 하는지에 대한 명명이라고 볼 수 있겠습니다,
예) ‘댓글 달기 기능을 테스트 한다’
예2) ‘댓글 달기 기능을 관리자 및 등록자 관점에서 테스트한다’
테스트한 기록을 남기는 수단을 테스트 노트라고 보시면 되겠습니다.
테스트 노트 예)
테스트 노트 | 결과 | 수행시간 | |
1 | 신규 게시글 작성 후 댓글 등록 | P | 10min |
2 | 댓글을 한 아이디로 반복 등록 | P | 10min |
3 | 댓글 단 아이디 탈퇴 후 댓글 확인 | F | 20mn |
특이사항 | 삭제된 계정의 댓글을 지울 수없음 댓글 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
장점실무활용 팁
참고 - Ad-hoc 테스트와 Random 테스트
-"예상결과를 사전에 정의하지 않고, 자의적이고 임의적으로 실행하는 테스트 활동" 과는 차이가 있다.
-이때 경험기반으로 테스트 해볼 수 있으나, 좀 더 목표 지향적이고 체계적으로 할 수 있도록 부분이 탐색적 테스팅 접근해 테스트하는 것을 탐색적 테스트라고 볼 수 있겠다.(개인의견)
Random 테스트
- "테스트 설계 기법을 통해 입력값을 따로 설정해 주지 않고 임의로 값을 선택해서 수행하는 방법" 과도 차이가 있다.