Ad-Hoc Testing과 Error Guessing
블랙박스 테스트 실무를 하다 보면 아래 상황이 생길 때가 많습니다.
정교한 테스트 디자인 없이 테스트 진행 필요한 경우
테스트 케이스로 발견하기 어려운 결함 식별 필요한 경우
빠른 시간에 테스트 커버리지를 보완해야 하는 경우
위 상황에서 효과적인 Error Guessing Test Technique을 통한 Ad-Hoc Testing에 대해 알아보겠습니다.
경험 기반 기법(Experience-based Techniques)
경험 기반 기법은 테스터의 직관, 기술, 유사 앱 사용 경험을 기반으로 테스트하는 방법을 뜻합니다. 실무에서는 체계적인 테스트 디자인 중심의 명세 기반 기법을 보완하는 형태로 활용하는데요. 가장 큰 특징으로는 테스터의 테스트 접근 방식과 경험에 따라 달성하는 테스트 커버리지 및 효과가 다양하게 나타나는 점입니다.
체크리스트 기반 테스팅 (Checklist-based Testing)
경험 기반 기법에는 대표적으로 많이 사용되는 체크리스트 기반 테스팅이 있습니다. 테스트 케이스와 달리 테스트 사전 조건과 테스트 스텝이 명확하지 않습니다. 주로 테스트 대상과 검증 필요한 내용에 대해서만 간단히 서술된 형태이고, 테스터의 역량에 따라 1개의 체크리스트에서 서로 다른 테스트 결과가 도출될 수 있습니다. 체크리스트 구성 요소 및 예시와 실제 활용 사례는 다른 게시물에서 다뤄보겠습니다.
탐색적 테스팅(Exploratory Testing)
탐색적 테스팅은 제임스 바크(James Bach)가 소개한 테스트 접근법 중 하나인데요. 핵심은 테스트 케이스의 문서화 시간을 최소화하고 테스터의 발견적인 지적 능력을 최대로 활용하여, 테스트 계획, 설계, 수행을 동시에 진행하는 것입니다. 오늘 소개할 Ad-Hoc Testing과의 가장 큰 차이점은 테스트 산출물 존재 여부인데요. 탐색적 테스팅 같은 경우 테스트 차터, 타임 박싱, 세션, 회고가 담긴 최소한의 산출물을 남기지만, Ad-Hoc Testing은 문서화 없이 진행되는 비공식 테스팅 중 하나입니다. 탐색적 테스팅 구성 요소 및 예시와 실제 활용 사례는 다른 게시물에서 다뤄보겠습니다.
오류 추정(Error Guessing)
마지막으로 오늘 주제와 밀접한 관련이 있는 오류 추정입니다. Ad-Hoc Testing의 유형 중 하나이고 실무에서 많이 활용하는 테스트 기법입니다.
오류 추정(Error Guessing)
오류 추정은 숙련된 테스터들이 활용하는 테스트 기법인데요, 다양한 테스팅 경험을 통해 어떤 상황에서 어떠한 문제가 발생하는지 추측하여 테스트에 활용하는 기법입니다. 정교한 테스트 디자인과 규칙 없이 진행된다는 점에서 경험과 역량에 전적으로 의존하기 때문에 테스트 결과 및 성과도 달라집니다. 오류 추정 진행 방법은 여러 가지인데요, 쉽고 빠른 활용 가능한 방법 1가지를 소개합니다.
BTS(버그 트래킹 시스템) 히스토리 분석
일반적으로 버그 추적 관리를 위해 맨티스, 지라, 레드 마인과 같은 버그 트래킹 툴을 사용합니다. 이슈의 우선순위 심각도 별로 구분할 수 있고 이슈 상태를 QA 차수별로 추적 관리 가능하여, 진행 중인 프로젝트의 모든 이슈 상황 분석이 가능합니다.
특히 결함 유형을 세분화시킨 조직 같은 경우 BTS에 등록된 결함을 보다 한눈에 파악하기 쉬운데요. 이러한 점을 활용하여 우선순위, 중요도, 결함 유형 분석을 통해 어떤 기능을 테스트할지 정할 수 있습니다.
또한 프로젝트 막바지에 보다 높은 완성도를 위한 테스팅이 필요할 경우, BTS에 등록된 결함을 차트 형태로 분석하여 결함 집중 원리에 따른 추가 테스팅 영역을 찾아낼 수 있습니다.
Ad-Hoc Testing
Ad-Hoc Testing은 정교한 테스트 디자인 없이 즉흥적이고 무작위로 수행되는 형태를 의미합니다. 빠른 시간에 결함을 찾아내는 것이 가장 큰 목적이며, 아래 상황에서 활용됩니다.
- 정교한 테스트 디자인 없이 테스트 진행 필요한 경우
- 테스트 케이스로 발견하기 어려운 결함 식별 필요한 경우
- 빠른 시간에 테스트 커버리지를 보완해야 하는 경우
앞서 설명한 오류 추정 방법 중 하나인 BTS 히스토리 분석을 통해 테스트 필요 대상이 좁혀졌다면, 경험과 직관을 통해 아래 내용을 고려한 테스트가 진행될 경우, 보다 효과적인 Ad-Hoc Testing이 가능합니다.
- 유효하지 않은 값 입력
- 데이터의 경곗값
- 입력 필드 빈칸 상태에서의 다음 단계 진행 시도
- 최대 한계치를 넘는 파일 업로드 시도
- 영어, 한글, 숫자 외의 특정 언어 또는 특수 문자 입력 시도
- 많은 클릭 또는 입력 시도
Ad-Hoc Testing 장점
Error Guessing 방법 중 BTS 분석을 통한 Ad-Hoc Testing 장점은 빠른 실행과 문서화에 대한 부담을 줄일 수 있기에 시스템의 전반적인 기능 이해와 버그 발견에만 집중할 수 있습니다.
또한 SDLC(Software Development Life Cycle)의 모든 단계에서 활용 가능하고, 최소한의 노력으로 테스트 케이스에서 발견하지 못했던 추가 결함을 발견할 수 있으며, 공식적인 테스트 케이스 기반의 활동에 결합하여 사용할 경우 더욱 효과적입니다.
특히 적절하지 못한 요구사항 분석으로 디자인된 테스트 케이스를 보완할 수 있으므로 프로젝트 막바지에 공식적인 방법으로 도출된 테스트 케이스가 모두 완료되었다면, 1시간 미만의 짧은 Ad-Hoc Testing은 효과적이고 중요합니다.
이 과정에서 중요한 결함을 발견할 수 있으며 요구사항 분석 시 놓쳤던 부분에 대한 보완점으로도 활용이 가능합니다. 테스트는 1가지 방법이 아닌 여러 형태의 방법을 결합하고 틀에 박힌 방식이 아닌, 유연한 사고로 상황에 따라 적절한 대응이 필요한 활동입니다.
Ad-Hoc Testing 단점
Ad-Hoc Testing 이 공식적인 테스트 활동이 될 수 없는 여러 가지 이유와 단점이 존재하는데요. 테스트 진행 상황 추적이 힘들고 테스트 범위가 불명확한 점과 더불어 숙련도 높은 테스터와 그렇지 않은 테스터의 테스트 결과가 천차만별이기 때문입니다.
앱 사용 경험에 따라 기술적으로 중요한 기능을 수행하지 않고 건너뛸 수도 있으며, 프로젝트에 이제 막 투입된 신입 테스터일 경우 이전에 발생했던 결함에 대한 회고와 추적 관리에 대한 경험이 다소 낮기 때문에, 불필요한 테스트로 이어질 가능성이 존재합니다.
기본적으로 경험 기반 기법은 테스터의 직관, 기술, 유사 앱 사용 경험을 기반으로 테스트하는 방법이기 때문에 체계적인 테스트 디자인 중심의 명세 기반 기법과 적절히 섞은 형태로 활용하는 것이 적절합니다.
정리
1. 경험 기반 기법에는 에러 추정, 체크리스트, 탐색적 테스팅과 같은 접근법이 있습니다. 에러 추정 방법에는 여러 방법이 있지만 일반적으로 가장 쉽고 빠르게 활용할 수 있는 BTS 버그 히스토리 분석을 알아보았습니다.
2. BTS 버그 히스토리 분석을 통해 정교한 테스트 디자인 없이 즉흥적이고 무작위로 수행되는 Ad-Hoc Testing을 보다 효과적인 방법으로 진행 가능합니다.
3. SDLC(Software Development Life Cycle)의 모든 단계에서 활용 가능한 Ad-hoc Testing은 적은 노력으로 공식적인 테스트 활동을 보완할 수 있고 테스트 케이스로 발견하지 못한 유형의 결함을 찾아낼 수 있다는 장점이 있지만, 테스트 추적 관리가 어렵고 숙련도에 따라 테스트 결과가 천차만별이기 때문에 테스트 결과에 대한 신뢰성 문제가 존재합니다. 이에 불필요한 테스트 활동으로 이어질 가능성이 높습니다.
4. 따라서 경험 기반 기법의 오류 추정과 애드혹 테스팅을 활용한 테스트 활동은, 공식적인 테스트 디자인을 통한 명세 기반 기법 수행 중심 테스팅을 보완하는 형태로 진행하는 것이 적절하고, 프로젝트 막바지 또는 진행 초기에 1시간 미만으로 탐색하는 것이 효과적입니다.
5. 준비한 테스트 케이스 수행은 모두 끝났지만 무언가 찝찝하고 부족하다 느낄 경우, 오류 추정 방법 중 BTS 버그 히스토리 분석을 통한 Ad-Hoc Testing을 진행해 보면 어떨까요? 명세 기반 기법에 경험 기반 기법을 다양한 형태로 결합하는 방법은 높은 테스트 커버리지 달성에 기여할 것입니다.
