본문 바로가기
QA/Theory

탐험적 테스팅(Exploratory Testing)

by 화뉘 2016. 3. 29.

탐색적 테스팅 접근법(Exploratory testing approach)

  • 테스트케이스 작성의 시간을 최소화하면서 테스트 엔지니어의 발견적인(Heuristic) 지적 능력을 최대한 활용하여 테스트를 수행하는 것
  • 테스트 설계, 테스트 수행, 테스트 계획, 테스트 기록 및 학습을 동시에 진행하는 휴리스틱한(Heuristic, 발견적인) 테스팅 접근법
  • 테스트 케이스를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서, 익숙해지는 것과 동시에 테스트를 설계하고 테스트를 계획한다.
  • 60~120분 동안에 몰입하여 수행할 수 있는 정도의 테스트 목적을 담고 있는 테스트 차터(Test Charter)를 기반으로 “제한된 시간(Time-Boxing)” 내에 테스팅의 “목적”을 정한 후, “몰입”하여 최소한의 설명 가능한 기록(Note)를 남기면서 테스트를 수행하고, 수행 후 “요약보고(Debriefing)”하는 것을 강조한다.
  • 테스트 케이스 기반의 공식적인 테스팅과 반대되는 개념의 “테스팅 접근법”
  • 최소한의 문서화를 통해 테스트를 실행하면서 분석/설계하고 계획을 세우는 것으 공식적인 테스팅 방법론보다 더 효율적이고 결함을 발견할 확률이 높아질 수 있다고 보는 테스팅 접근법
  • 공식적 테스팅이 문서화된 테스트 케이스를 기반으로 수행하는 것임에 반해, 탐색적 테스팅은 테스트 케이스를 문서화하는데 소요되는 시간을 최소화하여 테스트를 ”실행”하는 것에 집중한다.
  • 여러 테스팅 기법과 방법론을 훈련된 테스트 엔지니어가 많은 생각과 지적인 활동을 통해 창조적으로 테스팅하는 것을 강조
  • 탐색적 테스팅이 포함하는 내용
    • 제품 탐색(Product Exploration)
    • 테스트 설계(Test Design)
    • 테스트 실행(Test Execution)
    • 휴리스틱스(Heuristics)
    • 검토 가능한 결과물(Reviewable Results)
  • 탐색적 테스팅의 테스트 절차
    • 제품의 목적 식별(Identify the purpose of the product)
    • 기능 식별(Identify functions)
    • 잠재적으로 불안정한 부분 식별(Identify areas of potential instability)
    • 각각의 기능 테스트 및 문제점 기록(Test each function and record problem)
    • 일관성 검증 테스트 설계 및 기록(Design and record a consistency verification test)

탐색적 테스팅의 구성요소

  • 테스트 차터(Charter)와 시간 제한(Time Box)
    • 테스트 차터 : 무엇이 어떻게 테스트되어야 하고, 무슨 문제를 살펴야 하는지를 제안하는 내용
    • 테스트 차터를 정할 때에는 먼저 수행될 각 세션당 시간을 정해 놓는다.(Time box)
    • 테스터는 정해진 시간 내에 테스트 차터를 수행해야 하며, 몰입하여 테스트하는 것을 원칙으로 한다.
    • 테스터가 정해진 시간 안에 수행해야 할 것
      1. 정확한 리포팅(Accurate reporting)
      2. 유연성 있는 일정관리(Flexible scheduling)
      3. 테스트 방향 정정(Course correction)
      4. 견고한 테스팅(Solid testing done)
      5. 효율적인 요약 보고(Efficient debriefings)
    • 테스트 차터를 효율적/효과적으로 만들기 위해서는 제품 리스크 기반하여 만들어야 한다. 즉 리스크 분석 결과 제품의 리스크가 높은 기능에는 테스트 차터가 많이 생성하고, 리스크 낮은 기능에는 적게 생성하여 테스트를 수행하는 것이다.

예제) Test charters are used in ________ testing ( A )

a)      Exploratory testing

b)     Usability testing

c)      Component testing

d)     Maintainability testing

  • 테스트 노트(Test note)와 요약 보고(Debriefing)
    • 테스트 엔지니어는 테스트 실행과 동시에 머리 속에 계획, 설계하고 테스트 케이스를 작성하며, 이러한 사고활동을 간단하게 노트에 기록한다.
    • 작성한 테스트 노트는 테스트 케이스의 역할을 대처함과 동시에, 검토 가능한 결과물로써 활용된다.
    • 탐색적 테스팅의 한 세션이 종료된 후에는 팀원끼리 요약보고(Debriefing)하는 시간을 갖는다. 요약 보고 중에는 테스트 중 발견했던 결함과 이슈사항에 대해 보고하고, 어떤 식으로 테스트를 수행했는지에 관한 경험을 팀원 모두가 공유한다. 이러한 토론 과정을 통해 경험이 적은 테스터는 경험이 많고 뛰어난 테스터의 지도와 조언으로 스스로를 훈련시킬 수 있다.
    • 테스트 노트에 포함되어야 할 내용
      1. 테스트한 제품에 대한 노트 및 기록
      2. 발견된 결함과 장애에 대한 노트 및 기록
      3. 어떻게 테스트되었는지를 기술하는 요약된 문서
  • 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교
    • 테스트 케이스 기반 테스팅과 탐색적 테스팅의 가장 큰 차이점은 테스트 기반 테스팅은 모든 테스트 케이스의 작성을 마친 후 그것을 절차적으로 실행하지만, 탐색적 테스팅은 테스트 대상을 알게 되면서 동시에 테스트를 설계하고 실행하는 것이다.
    • 두 가지의 테스팅 방식이 발견하는 결함의 종류도 서로 다르다. 테스트 케이스 작성이 완료된 상태에서 테스트를 실행하게 되면 테스터 주체에 상관없이 같은 결함을 발견하지만, 탐색적으로 테스트할 경우 테스터의 성향(파괴적 테스터, 스크립트적 테스터, 사용성 테스터, 남/여 등)에 따라 서로 다른 결과를 산출하게 된다.
    • 탐색적 테스팅은 “자유로운 방식”에서 시작하여 스크립트 정도와 탐색적 정도에 따라 테스트 케이스 기반 방식으로 확장할 수 있다.

테스트 케이스 기반 테스팅

탐색적 테스팅

테스트가 먼저 설계되고 기록된다. 나중에 (때에 따라 다른 테스터가 이를 수행한다.)

테스트 설계됨과 동시에 수행된다. 테스트가 반드시 기록되어야 하는 것은 아니다.

[비유]준비된 연설과 같다. 테스트는 미리 착안된 생각에 따라 수행된다.

대화를 하는 것과 같다. 테스트는 아이디어를 반영하고, 생각을 발전시키는 방향으로 수행된다.

테스트의 실행을 관리하는 것이다.

(Controlling test execution.)

테스트 설계를 계속 향상 시키는 것이다.

(Improving test design.)

테스트 실행을 시작하기 전에 테스트 케이스를 작성한다.

프로젝트 기간 내내 테스트 계획/설계와 실행을 반복한다.

테스트 문서 작성, 검토에 많은 에너지를 소비함으로써, 생성될 테스트의 전체 수를 줄이는 경향이 있다.

테스트 문서 작성, 검토에 대한 필요성을 최소화하여 보다 많고 복잡한 테스트에 상대적으로 많은 노력 투자가 가능하다.

테스트 간의 (특성, 능력) 차이를 제거하려는 능력

테스트 간의 (특성, 능력) 차이를 십분 활용하려는 노력

테스터가 아닐 수 있는 테스트 설계자가 테스트를 설계한다.

테스트 설계자일 수 있는 테스터가 테스트를 설계한다.

완벽하게 한번에 테스팅을 수행한다.

점진적이고 주기적으로 테스팅을 수행한다.

    • 리스크가 가장 높은 곳에는 테스팅 경험이 가장 많고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행해야 하고, 반대로 리스크가 가장 낮은 곳에는 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행해야 한다.
  • 성공적인 탐색적 테스팅의 효과
    • 경험적으로 테스팅을 하는 것을 체계화 시킬 수 있다.
    • 테스트 케이스를 작성하는 시간을 줄여 보다 많은 테스트를 실행할 수 있다.
    • 테스터 또는 테스트 엔지니어의 역량을 월등히 향상시킬 수 있다.
    • 적은 테스트 인력으로 많은 테스트를 수행할 수 있다.
    • 명세가 거의 없고 시간이 부족한 경우 테스트를 효과적/효율적으로 수행할 수 있다.

'QA > Theory' 카테고리의 다른 글

version naming  (0) 2016.08.23
Bullseye를 이용한 Code Coverage Test  (0) 2016.03.30
Web Automation Test Tool Guide  (0) 2016.03.29
Pairwise testing  (0) 2016.03.29
Fit & FirNeses  (0) 2016.03.29

댓글