우리는 지금까지 테스트 계획서와 상세한 테스트 케이스를 기반으로 한, 체계적이고 구조적인 테스트에 대해 주로 이야기해 왔습니다. 이는 제품의 핵심 기능이 빠짐없이 검증되었음을 보장하는 매우 중요한 활동입니다.
하지만 만약, 이런 상세한 ‘지도(테스트 케이스)’ 없이, 오직 테스터의 경험과 직관에 의지해 ‘탐험’하듯 테스트한다면 어떨까요? 지도에는 없는, 예상치 못한 길에서 새로운 보물(버그)을 발견할 수도 있지 않을까요?
이러한 접근법이 바로 ‘탐색적 테스팅(Exploratory Testing)’입니다.
Q. 탐색적 테스팅, 정확히 무엇인가요?
테스트 케이스를 미리 상세하게 설계하지 않고, 테스터가 소프트웨어를 직접 사용해보며 ‘학습’, ‘테스트 설계’, ‘테스트 실행’을 동시에 진행하는 테스트 접근법입니다.
- 비유: 정해진 관광 코스를 따라가는 ‘패키지여행(스크립트 기반 테스트)’이 아닙니다. 지도 한 장만 들고 발길 닿는 대로 골목길을 누비며, 현지인만 아는 숨은 맛집을 찾아내는 ‘자유여행(탐색적 테스팅)’과 같습니다.
Q. 왜 테스트 케이스 없이 테스트하는 것이 중요한가요?
정해진 길(스크립트)로는 발견할 수 없는, 예상치 못한 결함을 찾아낼 수 있기 때문입니다.
- 인간의 창의성 활용: 테스터의 호기심과 직관을 통해, 설계 당시에는 미처 생각지 못했던 독특한 사용 시나리오를 시도해볼 수 있습니다.
- 빠른 피드백 제공: 문서 작업 시간을 줄이고, 제품을 직접 사용하며 즉각적인 피드백을 제공할 수 있어 개발 속도가 빠른 애자일 환경에 매우 적합합니다.
- 우연한 버그 발견: 여러 기능을 복합적으로 사용하거나, 비정상적인 순서로 조작하는 과정에서 스크립트 기반 테스트로는 놓치기 쉬운 ‘우연한’ 버그를 발견할 확률이 높습니다.
Q. ‘그냥 막 눌러보는 것’과 무엇이 다른가요?
이것이 가장 중요한 차이점입니다. 탐색적 테스팅은 ‘목표’와 ‘기록’이 있다는 점에서 단순한 랜덤 테스트와 명확히 구분됩니다.
- 1. 테스트 목표(Charter)가 있습니다:
- “회원가입부터 첫 상품 구매까지의 과정에서 불편한 점 찾기”와 같이 막연하지 않은, 명확한 탐색의 목표를 설정하고 시작합니다.
- 2. 학습하고 기록합니다:
- 테스트를 진행하며 발견한 새로운 사실, 시도해 본 경로, 느낀 점, 그리고 발견한 버그를 간결하게 기록합니다. 이 기록이 다음 탐색의 기반이 됩니다.
- 3. 시간제한(Timeboxing)을 둡니다:
- “90분 동안 이 기능에 대해 집중적으로 탐색한다”와 같이 시간을 정해두고, 그 시간 동안 최대한의 가치를 찾아내는 데 집중합니다.
Q. 언제 활용하면 가장 효과적인가요?
다른 테스트 활동을 보완할 때 가장 큰 힘을 발휘합니다.
- 새로운 기능이 막 개발되었을 때:
- 아직 테스트 케이스가 완벽하지 않을 때, 빠른 피드백을 주기 위해 사용합니다.
- 정식 테스트 케이스 실행 전후:
- 스크립트 테스트가 놓칠 수 있는 부분을 보완하기 위해 추가적으로 수행합니다.
- 요구사항이 불명확하거나 변경이 잦을 때:
- 상세한 문서를 만들기 어려운 상황에서, 제품을 직접 만져보며 품질을 점검하는 데 효과적입니다.
결론: 구조적인 테스트와 자유로운 탐색의 조화
탐색적 테스팅은 무계획적인 활동이 아닙니다. 이는 테스터의 지성과 창의성을 최대한으로 활용하는, 고도로 숙련된 테스트 기술입니다.
견고한 품질을 위해서는 두 가지 접근법이 모두 필요합니다. 스크립트 기반 테스트를 통해 ‘우리가 이미 알고 있는 중요한 길’들이 안전하다는 것을 보장하고, 탐색적 테스팅을 통해 ‘우리가 아직 알지 못하는 미지의 길’에 숨어있을지 모를 위험을 찾아내는 것입니다. 이 두 가지가 조화를 이룰 때, 비로소 테스트 커버리지는 완성에 가까워집니다.