소프트웨어 테스트는 종종 잘 짜인 요구사항 명세서와 그것을 충실히 검증하는 체계적인 테스트 케이스에서 시작됩니다. 하지만 모든 것을 문서화할 수는 없으며, 사용자의 예측 불가능한 행동이나 복잡한 시스템의 상호작용 속에서 발생하는 결함들은 명세서 기반 테스트만으로는 발견하기 어렵습니다.
이때 필요한 것이 바로 경험 기반 테스팅(Experience-Based Testing)입니다. 이것은 단순히 시나리오를 따르는 것을 넘어, 테스터의 지식, 직관, 그리고 비판적 사고를 무기 삼아 숨겨진 결함을 찾아내는 탐험가적 접근법입니다.
경험 기반 테스팅은 테스터의 경험, 기술, 직관을 주요 자원으로 활용하여 결함을 예측하고 테스트를 설계 및 수행하는 테스트 방법론의 한 갈래입니다.
이름 그대로, 이 테스트의 기반은 잘 쓰인 문서가 아니라, 테스터의 머릿속에 축적된 자산입니다. 여기에는 과거 프로젝트에서 겪었던 유사한 결함에 대한 기억, 해당 비즈니스 도메인에 대한 깊은 이해, 그리고 "왠지 이 부분에 문제가 있을 것 같다"고 느끼는 숙련된 직관 등이 모두 포함됩니다. 이는 정적인 테스트 케이스가 놓칠 수 있는 동적인 리스크를 찾아내는 데 매우 효과적인 접근법입니다.
경험 기반 테스팅은 무작위적인 테스트가 아니라, 다음과 같은 체계적인 사고 원리를 바탕으로 움직입니다.
테스터는 자신의 경험을 바탕으로 결함이 존재할 가능성이 높은 영역, 즉 '결함 집중 구역(Defect Cluster)'을 예측합니다. 예를 들어, "복잡한 계산 로직", "외부 시스템과의 연동 지점", "최근에 많은 변경이 있었던 모듈" 등이 주요 타겟이 됩니다. 이는 제한된 시간 안에 가장 중요한 결함을 찾아낼 확률을 높이는 지능적인 전략입니다.
경험 기반 테스팅, 특히 탐색적 테스팅에서는 테스트 설계와 실행이 분리되지 않습니다. 테스터는 시스템과 상호작용하며 실시간으로 제품에 대해 학습하고, 그 과정에서 얻은 새로운 정보를 바탕으로 다음 테스트 아이디어를 즉석에서 설계하고 실행합니다. 이는 마치 지도를 완성하며 동시에 미지의 대륙을 탐험하는 것과 같습니다.
자동화된 스크립트는 정해진 경로만을 검증하지만, 인간 테스터는 맥락을 이해하고 비판적으로 질문을 던질 수 있습니다. "이 기능은 스펙대로 동작하지만, 과연 사용자에게 편리할까?", "이 두 기능을 이런 순서로 사용하면 어떤 일이 벌어질까?" 와 같은 질문은 기계가 할 수 없는, 인간의 고유한 능력입니다. 경험 기반 테스팅은 이 능력을 극대화하는 것을 목표로 합니다.
이러한 원리를 바탕으로 다음과 같은 테스트 기법들이 널리 사용됩니다.
오해 1: "경험 기반 테스팅은 그냥 아무렇게나 막 해보는 것(Ad-hoc) 아닌가?"
진실: 잘 수행된 경험 기반 테스팅, 특히 탐색적 테스팅은 명확한 목표(테스트 차터)와 시간 관리(세션), 그리고 결과 기록 및 공유(디브리핑)라는 체계적인 구조를 가집니다. 이는 목표 없이 무작위로 수행하는 애드혹 테스트와는 근본적으로 다른, 매우 지능적인 활동입니다.
오해 2: "신입이나 경험 없는 테스터는 할 수 없다."
진실: 숙련된 전문가가 더 효과적인 것은 사실이지만, 신입 테스터도 경험 기반 테스팅을 수행할 수 있으며, 오히려 이를 통해 제품과 사용자에 대한 이해도를 가장 빠르게 높일 수 있습니다. 처음에는 잘 만들어진 체크리스트를 따르거나, 시니어와 함께 페어 탐색(Paired Exploratory Testing)을 진행하는 방식으로 시작할 수 있습니다.
오해 3: "문서화가 없어서 추적하기 어렵다."
진실: 탐색적 테스팅은 상세한 테스트 케이스 문서를 만들지 않을 뿐, 테스트 노트, 스크린샷, 영상 녹화 등 다양한 형태로 테스트 과정을 기록합니다. 세션 기반 테스트 관리(SBTM) 도구를 사용하면, 각 세션의 목표, 진행 상황, 발견한 이슈 등을 체계적으로 관리하고 추적할 수 있습니다.